Hello folks,
This thread is about sharing tricks about porting Android on new devices, and in particular how to reverse-engineer proprietary files with specific tools. Specifically, I'll use my experience on the camera part of the HTC ChaCha as an example.
Prerequisites
Install or reinstall the stock ROM
Make sure your device is rooted. If not, you might need to unlock the bootloader (for example, with the XTC Clip for HTC phones), install ClockworkMod and finally flash the Superuser package. There are many tutorials elsewhere on this so be sure to use the search button
Install adb from the SDK and (if using Windows) the required drivers for communicating with adbd on the phone or tablet. For HTC phones, here is a direct link to the driver: http://goo-inside.me/tools/USB_driver_20101122_release.zip
Modify your PATH so that adb is in it (optional but useful)
Install the NDK. Go into clockworkmod, run "adb shell mount /system", then "adb push /opt/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/gdbserver /system/bin/" and finally "adb shell chmod 755 /system/bin/gdbserver".
You will need to replace the path to gdbserver above with the correct path to your NDK installation.
Make a CWM backup of the stock ROM, so that you can switch easily from between stock and your CyanogenMod / AOSP build.
Install the free evaluation version of IDA Pro, see http://www.hex-rays.com/products/ida/support/download_demo.shtml
The general idea
We mostly use binary libraries from the stock ROM, so the important part is to understand how to communicate with them properly.
Note: the exception is the Linux kernel, because we don't use binary kernels from stock ROMs in CM7 and AOSP as they are generally incompatible and lack features (overclocking, pure bluetooth stack, ...). I'll probably make another thread about hacking kernel sources.
So we have to understand how things communicate with each other & the order and content of messages that are passed between components of the system. Reading the sources of Android is generally the best way to begin, to trace the interactions from the Java side of things up to the kernel.
Reverse-engineering of APKs with apktool, dex2jar & jd-gui
I'll complete this part shortly.
Static reverse-engineering of libcamera.so
In the case of the camera, a quick analysis of the source shows the Camera application uses the android.hardware.Camera class, which is mostly a bridge to the C++ file android_hardware_Camera.cpp, itself another bridge to the libcamera_client, which in turns calls the camera service inside the process "mediaserver" through a Binder (an Android-specific IPC mechanism). This architecture in theory allows concurrent access to the camera (but who does that?)
So the actual part that talks to the hardware is in libcameraservice, loaded by mediaserver at runtime. Examining the code in CameraService.cpp shows that is communicates with the proprietary libcamera.so through a C++ interface, CameraHardwareInterface.h.
This is where the stuff from HTC in the ChaCha starts to diverge from the original Android sources. Loading libcamera.so in IDA Pro allows us to look at the actual CameraHardwareInterface virtual table. It is actually easy to locate in IDA by searching for " `vtable for'android::QualcommCameraHardware". However IDA does not automatically detect it's a table of function pointers, so use the Edit->Array with a size of 46 and an entry size of 4 (the size of a pointer).
By manually comparing the list of pointers to the CameraHardwareInterface.h in the CM7 sources, one can see two functions that can be added with the USE_GETBUFFERINFO in BoardConfig.mk define: getBufferInfo and encodeData. There is however another third function not present in CameraHardwareInterface.h, setFaceDetectionState(), just after getParameters(). Thus we have to add this function to CameraHardwareInterface.h so that the virtual table matches the one in libcamera.so.
Now it's also interesting to compare the list of symbols between libraries from different ROMs. In this case, we can try to extract the camera parameters in HTC's ROM, and see if they match the symbols in CM7. The supported list of parameters is provided in libcamera_client.so. Use the program objdump from the NDK to retrieve the list of symbols and have them sorted (if using Windows, you'll need Cygwin):
Code:
/opt/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/arm-linux-androideabi/bin/objdump -T libcamera_client-cm7.so |cut -d '_' -f 2- > sym-camera_client-cm7
/opt/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/arm-linux-androideabi/bin/objdump -T libcamera_client-htc.so |cut -d '_' -f 2- > sym-camera_client-htc
diff -u sym-camera_client-cm7 sym-camera_client-htc
There are a bunch of new interesting symbols not present in CM7. Some of them seem related to HTC's Ola face detection engine, whilst others are unknown:
Code:
+ZN7android16CameraParameters27KEY_PREVIEW_FRAME_RATE_MODEE
+ZN7android16CameraParameters16KEY_CAPTURE_MODEE
+ZN7android16CameraParameters17KEY_PICTURE_COUNTE
+ZN7android16CameraParameters27KEY_MAX_BURST_PICTURE_COUNTE
+ZN7android16CameraParameters19KEY_TOUCH_INDEX_AECE
+ZN7android16CameraParameters18KEY_TOUCH_INDEX_AFE
+ZN7android16CameraParameters16KEY_SCENE_DETECTE
+ZN7android16CameraParameters26KEY_SUPPORTED_SCENE_DETECTE
+ZN7android16CameraParameters23KEY_TAKING_PICTURE_ZOOME
+ZN7android16CameraParameters22KEY_SELECTABLE_ZONE_AFE
+ZN7android16CameraParameters32KEY_SUPPORTED_SELECTABLE_ZONE_AFE
...
Debugging libcamera.so
At this point it would be a bit time-consuming to statically check all code paths within the stock ROM to see what parameters are actually used when taking a normal picture. A easier way is to break into the setParameter function within libcamera to inspect at runtime the arguments. We'll use gdb for this.
Run "adb forward tcp:1234 tcp:1234" to forward the TCP port used by gdbserver. Then run an adb shell, then "su" to become root, then list the processes with "ps", and finally run "gdbserver :1234 --attach <pid of mediaserver>".
Not on the phone, but on the host, extract the libraries and mediaserver, then run gdb:
Code:
mkdir lib
cd lib
adb pull /system/lib
adb pull /system/bin/mediaserver
adb pull /system/bin/linker
/opt/android-ndk-r7/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-gdb mediaserver
In the gdb command prompt, enter "set height 0", "set solib-search-path ./" and then "target remote 127.0.0.1:1234". gdb should then show the loading of all .so files, such as "Reading symbols from /root/chacha/system/lib/libarimedia.so...
(no debugging symbols found)...done.". Sometimes nothing is shown, if so start over (exit gdb, reattach gdbserver, restart gdb).
Now we can set breakpoints on the functions that interest us. Open libcamera.so in IDA Pro, also have a look at the list of symbols with objdump -T. The following functions are of particular interest:
Code:
_ZN7android16CameraParameters3setEPKci
_ZN7android16CameraParameters3setEPKcS2_
In the ARM binary calling convention, parameters are passed in registers r4 to r8 (instead of say, 32-bit x86 where parameters are pushed on the stack). Let's examine what they point to at runtime:
Code:
(gdb) break _ZN7android16CameraParameters3setEPKci
Breakpoint 5 at 0xaba8eef4
(gdb) break _ZN7android16CameraParameters3setEPKcS2_
Breakpoint 6 at 0xaba8ed14
(gdb) cont
Continuing.
[New Thread 923]
[Switching to Thread 923]
Breakpoint 6, 0xaba8ed14 in android::CameraParameters::set () from /root/chacha/system/lib/libcamera_client.so
(gdb) x/1s $r4
0xaba9100c <_ZN7android16CameraParameters16KEY_PREVIEW_SIZEE>: "preview-size"
(gdb) x/1x $r5
0xafd4d6e8 <__stack_chk_guard>: 0x10997eaa
(gdb) x/1s $r5
0xafd4d6e8 <__stack_chk_guard>: "�~\231\020"
(gdb) x/1s $r6
0x411139cc: "640x384"
(gdb) x/1s $r7
0x30d0c: "h8��\210\f\003"
(gdb) x/1s $r8
0xa811d251 <__dso_handle+512417>: "�\205h\203�\ahFh�h����"
(gdb) cont
Continuing.
So we see the first parameter is passed in r4 and the second in r6. Likewise, for breakpoint 5we can examine the registers and see the parameters r7 and r5. Now let's enable logging and automatically dump the arguments each time a breakpoint is hit, then resume execution:
Code:
(gdb) set logging on
Copying output to gdb.txt.
(gdb) commands 5
Type commands for when breakpoint 5 is hit, one per line.
End with a line saying just "end".
>x/1s $r7
>x/1s $r5
>cont
>end
(gdb) commands 6
Type commands for when breakpoint 6 is hit, one per line.
End with a line saying just "end".
>x/1s $r4
>x/1s $r6
>cont
>end
Finally, here's the juicy bits we wanted
Code:
(gdb) cont
Continuing.
Breakpoint 5, 0xaba8eef4 in android::CameraParameters::set () from /root/chacha/system/lib/libcamera_client.so
0xaba9106c <_ZN7android16CameraParameters33KEY_SUPPORTED_PREVIEW_FRAME_RATESE>: "preview-frame-rate-values"
0x411139dc: "15"
Breakpoint 6, 0xaba8ed14 in android::CameraParameters::set () from /root/chacha/system/lib/libcamera_client.so
0xaba914a4 <_ZN7android16CameraParameters22KEY_VIDEO_FRAME_FORMATE>: "video-frame-format"
0xa7912c16 <__dso_handle+4262342>: "yuv420sp"
Breakpoint 6, 0xaba8ed14 in android::CameraParameters::set () from /root/chacha/system/lib/libcamera_client.so
0xaba91030 <_ZN7android16CameraParameters18KEY_PREVIEW_FORMATE>: "preview-format"
0xa7912c16 <__dso_handle+4262342>: "yuv420sp"
Breakpoint 6, 0xaba8ed14 in android::CameraParameters::set () from /root/chacha/system/lib/libcamera_client.so
0xaba91110 <_ZN7android16CameraParameters16KEY_PICTURE_SIZEE>: "picture-size"
0x411139cc: "2592x1952"
Breakpoint 6, 0xaba8ed14 in android::CameraParameters::set () from /root/chacha/system/lib/libcamera_client.so
0xaba91134 <_ZN7android16CameraParameters18KEY_PICTURE_FORMATE>: "picture-format"
0xa79120a5 <__dso_handle+4259413>: "jpeg"
Breakpoint 6, 0xaba8ed14 in android::CameraParameters::set () from /root/chacha/system/lib/libcamera_client.so
0xaba911f8 <_ZN7android16CameraParameters16KEY_JPEG_QUALITYE>: "jpeg-quality"
0xa7912bb9 <__dso_handle+4262249>: "100"
... and so on
If mediaserver crashes or stop responding, as a worst case you may have to reboot the phone, as the Linux kernel doesn't always properly cleanup dead debugged processes.
Then the operation can be repeated but with CM7 instead of stock ROM, and the gdb.txt output files compared for any modifications. Now this is just the beginning, but hopefully I've showed you a taste of how to do reverse-engineering on Android and I hope it'll help make this area of work less obscure to newcomers
This post reserved for future updates, references, examples and so on.
That's amazing teaching material, thanks for that Xdbg!
Btw, I found that presentation by Defer quite interesting also: http://www.slideshare.net/deovferreira/from-stock-to-cyanogenmod-the-sony-ericsson-case . Have a look at slides 68 and next.
Thanks, xdbg!
In the past I was able to debug native libs of Swype to crack its security and of Angry Birds to get its encryption keys. It was a lot of fun ;-D
I was using similar technique to you - Angry Birds hacking is described here: http://forum.xda-developers.com/showpost.php?p=12853986&postcount=19 . But I'm totally new to native debugging, so I was using a lot of tricks and workarounds. Your technique is much more mature
Thanks again.
Brut.all said:
Thanks, xdbg!
In the past I was able to debug native libs of Swype to crack its security and of Angry Birds to get its encryption keys. It was a lot of fun ;-D
I was using similar technique to you - Angry Birds hacking is described here: http://forum.xda-developers.com/showpost.php?p=12853986&postcount=19 . But I'm totally new to native debugging, so I was using a lot of tricks and workarounds. Your technique is much more mature
Thanks again.
Click to expand...
Click to collapse
Hey very nice, defeating software protections is also a lot of fun I'm glad you find this short tutorial useful!
Unfortunately the evaluation version of IDA Pro does not contain the gdb client plugin, which would have been ideal to debug with a GUI. At the moment we'd have to either pirate it (which I of course condone) or buy it -- it costs about $400 iirc
EDIT: OMG, you're the author of apktool! I'm a huge fan, I use it all the time
tips!
Great tips! TNX!
Thx, useful info.
thank you for sharing!!! i didn't know it was possible to debug too!!!
Demangling compiled C++ names
I believe it can be interesting, I've just found out that you can automatically demangle compiled C++ names using c++filt:
Say you have:
Code:
export PATH=~/android/cm9/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin/:$PATH
then you can run:
Code:
arm-eabi-objdump -T libcamera.so | arm-eabi-c++filt
It will produce something like:
Code:
...
0000e088 g DF .text 00000b8c android::QualcommCameraHardware::initDefaultParameters()
00000000 DF *UND* 00000000 android::CameraParameters::setPreviewFrameRate(int)
00000000 DF *UND* 00000000 android::CameraParameters::setPreviewFormat(char const*)
00000000 DO *UND* 00000000 android::CameraParameters::KEY_SUPPORTED_PREVIEW_FRAME_RATES
00000000 DO *UND* 00000000 android::CameraParameters::KEY_VIDEO_FRAME_FORMAT
...
This is very nice! Thanks for sharing this information with us
i'm stuck here! what's the problem?
warning: while parsing target library list (at line 2): No segment defined for /
system/bin/mediaserver
0x4019eacc in __ioctl () from libc.so
Code:
media 4719 1 37452 9616 ffffffff 4019eacc T /system/bin/mediaserver
root 4735 2 0 0 c0195f74 00000000 S kworker/u:3
system 4736 210 318980 38056 ffffffff 4002e868 S com.android.settings:remo
te
app_17 4755 210 306468 37164 ffffffff 4002e868 S com.htc.calendar
app_17 4770 210 303944 37248 ffffffff 4002e868 S com.htc.bgp
app_175 4796 210 317960 42636 ffffffff 4002e868 S com.google.android.apps.m
aps:NetworkLocationService
app_175 4821 210 309512 38256 ffffffff 4002e868 S com.google.android.apps.m
aps:FriendService
app_11 4842 210 305784 35312 ffffffff 4002e868 S com.android.bluetooth
app_199 4868 210 301900 36220 ffffffff 4002e868 S com.vital.TouchScreenTune
root 4904 2 0 0 c0195f74 00000000 S kworker/u:1
root 4905 2 0 0 c0195f74 00000000 S kworker/0:2
root 4912 283 872 444 c0109558 400942b4 S /system/bin/sh
root 4917 4912 872 444 c0109558 400232b4 S sh
root 4927 2 0 0 c0195f74 00000000 S kworker/u:2
root 4953 2 0 0 c0195f74 00000000 S kworker/0:0
root 4955 4917 1052 380 00000000 4003b898 R ps
[email protected]:/ # gdbserver :1234 --attach 4719
gdbserver :1234 --attach 4719
Attached; pid = 4719
Listening on port 1234
Remote debugging from host 127.0.0.1
libthread_db:td_ta_new: Probing system for platform bug.
libthread_db:td_ta_new: Running as root, nothing to do.
Code:
(gdb) set height 0
(gdb) set solib-search-path ./
(gdb) target remote 127.0.0.1:1234
Remote debugging using 127.0.0.1:1234
warning: while parsing target library list (at line 2): No segment defined for /
system/bin/mediaserver
0x4019eacc in __ioctl () from libc.so
(gdb) info sharedlibrary
warning: while parsing target library list (at line 2): No segment defined for /
system/bin/mediaserver
From To Syms Read Shared Object Library
0xb0001000 0xb00068b4 Yes (*) C:\Users\Fabiano\ones\system\lib/linker
0x4019e420 0x401cc704 Yes (*) libc.so
0x400d9934 0x400d9a3c Yes (*) libstdc++.so
0x40093f70 0x400a3db8 Yes (*) libm.so
0x4003c028 0x4003d574 Yes (*) liblog.so
0x400abab0 0x400b48c4 Yes (*) libcutils.so
0x400232e0 0x40034100 Yes (*) libz.so
0x40217ce0 0x4022c580 Yes (*) libutils.so
0x40319570 0x40331368 Yes (*) libstlport.so
0x402ef330 0x402fd078 Yes (*) libGLESv2_dbg.so
0x402c498c 0x402d4250 Yes (*) libEGL.so
0x4008f22c 0x4008fb50 Yes (*) libwpa_client.so
0x40338928 0x4033a6ec Yes (*) libhostapd_client.so
0x400d25c8 0x400d4f90 Yes (*) libnetutils.so
0x400c9910 0x400cd48c Yes (*) libhardware_legacy.so
0x4007aba8 0x4008a220 Yes (*) libpixelflinger.so
0x400d76cc 0x400d78c4 Yes (*) libhardware.so
0x40473300 0x40473720 Yes (*) libemoji.so
0x404774e0 0x404a7260 Yes (*) libjpeg.so
0x400dce88 0x400eabf0 Yes (*) libexpat.so
0x40373960 0x4043dc4c Yes (*) libskia.so
0x404c3fa0 0x404cda1c Yes (*) libbinder.so
0x404d6744 0x404d6dfc Yes (*) libgenlock.so
0x402ad8f0 0x402b60e4 Yes (*) libui.so
0x404dc8b8 0x404ed490 Yes (*) libsonivox.so
0x406278d8 0x40627d24 Yes (*) libgabi++.so
0x40554610 0x405e8ef0 Yes (*) libicuuc.so
0x4067e564 0x4067f8f4 Yes (*) libGLESv2.so
0x40686794 0x40688700 Yes (*) libmemalloc.so
0x40681afc 0x4068208c Yes (*) libQcomUI.so
0x40665400 0x40670c58 Yes (*) libgui.so
0x4063c958 0x40641464 Yes (*) libcamera_client.so
0x40690ad8 0x40693cdc Yes (*) libstagefright_foundation.so
0x406db640 0x407a3610 Yes (*) libicui18n.so
0x4026a070 0x40284ae4 Yes (*) libmedia.so
0x4004ce90 0x400668ec Yes (*) libsrscorehtc.so
0x407bab54 0x407bb560 Yes (*) libeffects.so
0x407bec00 0x407bf030 Yes (*) libpowermanager.so
0x407c5014 0x407c5cd4 Yes (*) libdumppcm.so
0x400020a8 0x40002b38 Yes (*) libsrsprocessing.so
0x40115980 0x40134a28 Yes (*) libaudioflinger.so
0x407d08f4 0x407d4470 Yes (*) libcameraservice.so
0x40841d78 0x4084d14c Yes (*) libvorbisidec.so
0x4097b6a0 0x409e4040 Yes (*) libcrypto.so
0x40a2665c 0x40a3eb60 Yes (*) libssl.so
0x4091fc48 0x4093ea00 Yes (*) libnativehelper.so
0x40a4e790 0x40a8ff00 Yes (*) libsqlite.so
0x40b5fcc4 0x40b605f0 Yes (*) libqc-opt.so
0x40abc000 0x40b35e44 Yes (*) libdvm.so
0x40b64fe4 0x40b669f4 Yes (*) libGLESv1_CM.so
0x40b685e8 0x40b69210 Yes (*) libETC1.so
0x400ef498 0x400ef9d4 Yes (*) libnfc_ndef.so
0x40b6bedc 0x40b6c724 Yes (*) libusbhost.so
0x40b71e78 0x40ba3cc4 Yes (*) libharfbuzz.so
0x40bb6cc0 0x40bcc548 Yes (*) libhwui.so
0x40bd3b54 0x40bd3d74 Yes (*) libtilerenderer.so
0x40bdbecc 0x40be58fc Yes (*) libbluetooth.so
0x40bd59b8 0x40bd62ec Yes (*) libbluedroid.so
0x40bf7a68 0x40c12c6c Yes (*) libdbus.so
0x40895bc0 0x408e6838 Yes (*) libandroid_runtime.so
0x40ddddb0 0x40dde680 Yes (*) libstagefright_yuv.so
0x40dedb64 0x40df3320 Yes (*) libdrmframework.so
0x40efabf8 0x40efc7c0 Yes (*) libdiag.so
0x40e5001c 0x40e5e7d8 Yes (*) libaudcal.so
0x40e00a60 0x40e045e4 Yes (*) libacdbloader.so
0x40df8af8 0x40dfd49c Yes (*) libalsa-intf.so
0x40fd0708 0x411052dc Yes (*) libchromium_net.so
0x41187764 0x4118a6d0 Yes (*) libstagefright_amrnb_common.so
0x411935c4 0x4119367c Yes (*) libstagefright_enc_common.so
0x411961f0 0x41199194 Yes (*) libstagefright_avc_common.so
0x40c810f8 0x40d6cb04 Yes (*) libstagefright.so
0x411c5c54 0x411ca5f8 Yes (*) libstagefright_omx.so
0x407fe590 0x40825dec Yes (*) libmediaplayerservice.so
0x4000db48 0x4000f03c Yes (*) libbeatscorehtc.so
0x411a1210 0x411a91e4 Yes (*) audio.primary.default.so
0x411adc78 0x411af048 Yes (*) libhtc_acoustic.so
0x411b37f8 0x411b6024 Yes (*) alsa.default.so
0x413e19c0 0x413e2834 Yes (*) libbt-aptx-4.0.3.so
0x413e7a08 0x413e81f8 Yes (*) libpower.so
0x415f48b0 0x41600a64 Yes (*) audio.a2dp.default.so
0x411b9aa4 0x411b9cf0 Yes (*) libstagefrighthw.so
0x413eaf14 0x413ec8b4 Yes (*) libOmxCore.so
0x4162c308 0x4175edf0 Yes (*) libaricentomxplugin.so
0x413f1820 0x413f23fc Yes (*) libstagefright_soft_vorbisdec.so
0x41523398 0x415252a0 Yes (*) libgemini.so
0x41500570 0x4151dcfc Yes (*) libmmjpeg.so
0x41528bc0 0x4152a1f8 Yes (*) libsysutils.so
0x41533668 0x415337f8 Yes (*) libjnigraphics.so
0x41e7f330 0x41ea5ca4 Yes (*) libOlaEngine.so
0x4152eff8 0x41530dd8 Yes (*) libcameraface.so
0x41535348 0x41535358 Yes (*) libsurfaceflinger_client.so
0x419d9fa8 0x41a95550 Yes (*) libcamerapp.so
0x41e4dd78 0x41e67894 Yes (*) camera.msm8960.so
0x4153d948 0x4154357c Yes (*) audio_policy.default.so
(*): Shared library is missing debugging information.
(gdb)
Hi Fabiano,
Looks good to me. Did you try to simply resume execution of mediaserver with "cont"?
:good: Thank you! It was so simple...
I'm curious: why we attach mediaserver? Because it needs library "libcameraservice.so", and "libcameraservice.so" needs "libcamera_client.so", so when mediaserver is started, it loads all library needed and we can debug them?
An other question, for example, I want to change values at 0x1635aa0: "5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31"
What is mapped at 0x1635aa0? (I think that these values are stored in the kernel, but I'm not sure. Is there a way to check?)
I was searching here \drivers\media\video\msm\sensors\s5k3h2yx_v4l2.c (since HTC One S uses a s5k3h2yx sensor and build config point to that file)
s5k3h2yx_v4l2.c is attached belowe as s5k3h2yx.txt, i'm on the right way, or these value are not here?
Code:
0x4061d958 0x40622464 Yes (*) libcamera_client.so
Breakpoint 2, 0x4063649e in android::CameraParameters::set(char const*, char const*) () from libcamera_client.so
x1/s
r4 0x40639af0 <_ZN7android16CameraParameters33KEY_SUPPORTED_PREVIEW_FRAME_RATESE>: "preview-frame-rate-values"
r5 0x153c99c: "X¿[email protected](Tc\001\a"
r6 0x41ec2e08: ""
r7 0x426de95c: "`Yc\001\030Yc\001¨émBèXc\001àWc\001Ð1c\001¸Wc\001\220Wc\001hWc\001ÀVc\001hVc\001Tå¤A\030Vc\001ØUc\001\220Uc\001hUc\001ÜxëAøTc\001ÐTc\001¨Tc\001\200Tc\001HQc\001hSc\[email protected]\001¸Rc\001àQc\001HQc\001\001"
r8 0x1635aa0: "5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31"
x1/x
r4 0x40639af0 <_ZN7android16CameraParameters33KEY_SUPPORTED_PREVIEW_FRAME_RATESE>: 0x70
r5 0x153c99c: 0x58
r6 0x41ec2e08: 0x00
r7 0x426de95c: 0x60
r8 0x1635aa0: 0x35
now i know for sure that these value are not hardcoded in the libs since 0x1635aa0 is out of libs memory zone:
Code:
From To Syms Read Shared Object Library
0xb0001000 0xb00068b4 Yes (*) C:\Program Files (x86)\Android\android-ndk-r8b\toolchains\arm-linux-androideabi-4.4.3\prebuilt\windows\bin/linker
0x4014b420 0x40179704 Yes (*) libc.so
0x40190934 0x40190a3c Yes (*) libstdc++.so
0x40193f70 0x401a3db8 Yes (*) libm.so
0x4013c028 0x4013d574 Yes (*) liblog.so
0x40070ab0 0x400798c4 Yes (*) libcutils.so
0x400132e0 0x40024100 Yes (*) libz.so
0x401eece0 0x40203580 Yes (*) libutils.so
0x402d7570 0x402ef368 Yes (*) libstlport.so
0x402ad330 0x402bb078 Yes (*) libGLESv2_dbg.so
0x4028298c 0x40292250 Yes (*) libEGL.so
0x4000e22c 0x4000eb50 Yes (*) libwpa_client.so
0x4008e928 0x400906ec Yes (*) libhostapd_client.so
0x400955c8 0x40097f90 Yes (*) libnetutils.so
0x40005910 0x4000948c Yes (*) libhardware_legacy.so
0x402fdba8 0x4030d220 Yes (*) libpixelflinger.so
0x400106cc 0x400108c4 Yes (*) libhardware.so
0x4004a300 0x4004a720 Yes (*) libemoji.so
0x404474e0 0x40477260 Yes (*) libjpeg.so
0x4047ce88 0x4048abf0 Yes (*) libexpat.so
0x40346960 0x40410c4c Yes (*) libskia.so
0x404a7fa0 0x404b1a1c Yes (*) libbinder.so
0x40046744 0x40046dfc Yes (*) libgenlock.so
0x400358f0 0x4003e0e4 Yes (*) libui.so
0x404bd8b8 0x404ce490 Yes (*) libsonivox.so
0x406088d8 0x40608d24 Yes (*) libgabi++.so
0x40535610 0x405c9ef0 Yes (*) libicuuc.so
0x4065f564 0x406608f4 Yes (*) libGLESv2.so
0x40667794 0x40669700 Yes (*) libmemalloc.so
0x40662afc 0x4066308c Yes (*) libQcomUI.so
0x40646400 0x40651c58 Yes (*) libgui.so
0x4061d958 0x40622464 Yes (*) libcamera_client.so
0x40671ad8 0x40674cdc Yes (*) libstagefright_foundation.so
0x406bc640 0x40784610 Yes (*) libicui18n.so
0x40241070 0x4025bae4 Yes (*) libmedia.so
0x401b5e90 0x401cf8ec Yes (*) libsrscorehtc.so
0x40043b54 0x40044560 Yes (*) libeffects.so
0x4079cc00 0x4079d030 Yes (*) libpowermanager.so
0x407a3014 0x407a3cd4 Yes (*) libdumppcm.so
0x407a90a8 0x407a9b38 Yes (*) libsrsprocessing.so
0x400be980 0x400dda28 Yes (*) libaudioflinger.so
0x407b48f4 0x407b8470 Yes (*) libcameraservice.so
0x40825d78 0x4083114c Yes (*) libvorbisidec.so
0x4095f6a0 0x409c8040 Yes (*) libcrypto.so
0x40a0a65c 0x40a22b60 Yes (*) libssl.so
0x40903c48 0x40922a00 Yes (*) libnativehelper.so
0x40a32790 0x40a73f00 Yes (*) libsqlite.so
0x40b43cc4 0x40b445f0 Yes (*) libqc-opt.so
0x40aa0000 0x40b19e44 Yes (*) libdvm.so
0x40b48fe4 0x40b4a9f4 Yes (*) libGLESv1_CM.so
0x40b4c5e8 0x40b4d210 Yes (*) libETC1.so
0x40b4f498 0x40b4f9d4 Yes (*) libnfc_ndef.so
0x40b51edc 0x40b52724 Yes (*) libusbhost.so
0x40b57e78 0x40b89cc4 Yes (*) libharfbuzz.so
0x40b9ccc0 0x40bb2548 Yes (*) libhwui.so
0x40bb9b54 0x40bb9d74 Yes (*) libtilerenderer.so
0x40bc1ecc 0x40bcb8fc Yes (*) libbluetooth.so
0x40bbb9b8 0x40bbc2ec Yes (*) libbluedroid.so
0x40bdda68 0x40bf8c6c Yes (*) libdbus.so
0x40879bc0 0x408ca838 Yes (*) libandroid_runtime.so
0x40dc3db0 0x40dc4680 Yes (*) libstagefright_yuv.so
0x40dd3b64 0x40dd9320 Yes (*) libdrmframework.so
0x40ee0bf8 0x40ee27c0 Yes (*) libdiag.so
0x40e3601c 0x40e447d8 Yes (*) libaudcal.so
0x40de6a60 0x40dea5e4 Yes (*) libacdbloader.so
0x40ddeaf8 0x40de349c Yes (*) libalsa-intf.so
0x40fb6708 0x410eb2dc Yes (*) libchromium_net.so
0x4116d764 0x411706d0 Yes (*) libstagefright_amrnb_common.so
0x411795c4 0x4117967c Yes (*) libstagefright_enc_common.so
0x4117c1f0 0x4117f194 Yes (*) libstagefright_avc_common.so
0x40c670f8 0x40d52b04 Yes (*) libstagefright.so
0x411a6c54 0x411ab5f8 Yes (*) libstagefright_omx.so
0x407e2590 0x40809dec Yes (*) libmediaplayerservice.so
0x41193b48 0x4119503c Yes (*) libbeatscorehtc.so
0x41187210 0x4118f1e4 Yes (*) audio.primary.default.so
0x41197c78 0x41199048 Yes (*) libhtc_acoustic.so
0x413b17f8 0x413b4024 Yes (*) alsa.default.so
0x413ca9c0 0x413cb834 Yes (*) libbt-aptx-4.0.3.so
0x413d0a08 0x413d11f8 Yes (*) libpower.so
0x415e98b0 0x415f5a64 Yes (*) audio.a2dp.default.so
0x413d3aa4 0x413d3cf0 Yes (*) libstagefrighthw.so
0x413d5f14 0x413d78b4 Yes (*) libOmxCore.so
0x41621308 0x41753df0 Yes (*) libaricentomxplugin.so
0x413dc820 0x413dd3fc Yes (*) libstagefright_soft_vorbisdec.so
0x414f0398 0x414f22a0 Yes (*) libgemini.so
0x415c5570 0x415e2cfc Yes (*) libmmjpeg.so
0x414f5bc0 0x414f71f8 Yes (*) libsysutils.so
0x41500668 0x415007f8 Yes (*) libjnigraphics.so
0x41ca6330 0x41cccca4 Yes (*) libOlaEngine.so
0x414fbff8 0x414fddd8 Yes (*) libcameraface.so
0x41502348 0x41502358 Yes (*) libsurfaceflinger_client.so
0x41dcdfa8 0x41e89550 Yes (*) libcamerapp.so
0x419cdd78 0x419e7894 Yes (*) camera.msm8960.so
0x41535948 0x4153b57c Yes (*) audio_policy.default.so
Hi!
You can check the memory map by printing /proc/<your process pid>/maps, such as:
Code:
~ $ cat /proc/`pidof a.out`/maps
00400000-00401000 r-xp 00000000 08:02 6337054 /home/abc/a.out
00600000-00601000 rw-p 00000000 08:02 6337054 /home/abc/a.out
7ffff7a56000-7ffff7bd3000 r-xp 00000000 08:02 13642881 /lib/x86_64-linux-gnu/libc-2.13.so
...
As far as modifying data goes, it is fairly easy to do when you whan to write one byte or one word, for example "set *(char *)$MYREGISTER=0xff"
You can write a larger piece of data with the command restore (you need a writable place, like the stack). As an illustration of restoring the truth:
Code:
~ $ cat a.c
#include <stdio.h>
int f(int i1, int i2, char *c)
{
printf("You better believe me: %s\n", c);
return 0;
}
int main(void)
{
return f(1, 2, "HTC is not evil");
}
~ $ gcc a.c
~ $ echo "HTC is evil" >raw
~ $ gdb a.out
GNU gdb (GDB) 7.4.1-debian
[...]
(gdb) break f
Breakpoint 1 at 0x400510
(gdb) run
Starting program: /home/abc/a.out
Breakpoint 1, 0x0000000000400510 in f ()
(gdb) x/1s $rdx
0x400627: "HTC is not evil"
(gdb) print $rsp-0x1000
$2 = (void *) 0x7fffffffd370
(gdb) restore raw binary 0x7fffffffd370
Restoring binary file raw into memory (0x7fffffffd370 to 0x7fffffffd37c)
(gdb) set $rdx=0x7fffffffd370
(gdb) cont
Continuing.
You better believe me: HTC is evil
By the way, the value of interest to you could come (in theory) from lots of places, but most likely the Camera app, of some place in the framework. Consider disassembling both to check the contents.
Already done (everything is in Java at this level so it can be decompiled almost to source code, so it's the first thing i did), framework just contains Google APIs that call *.so lib functions, and just explodes a full string to single values (but full string is sent by libs)
camera apps (or other apps as well) can only set supported parameters by calling Google APIs (that call libs), if i want to set a non standard value, libs check the value and reply with an error (unsupported parameter, changing it to a default one). So values are stored in low level.
Maybe values are in the libs, but i don't know how some structs are stored in low level assembly, maybe i cannot find them because of my ignorance
In some open source camera HAL libs (for other phones but should be similar) i found some structs like these:
Code:
const char *preview_sizes =
"1280x720,800x480,768x432,720x480,640x480,576x432,480x320,384x288,352x288,320x240,240x160,176x144";
const char *video_sizes =
"1280x720,800x480,720x480,640x480,352x288,320x240,176x144";
const char *preferred_size = "640x480";
const char *preview_frame_rates = "30,27,24,15";
const char *preferred_frame_rate = "15";
const char *frame_rate_range = "(15,30)";
or
Code:
const char CameraHardware::supportedPictureSizes [] = "640x480,352x288,320x240";
const char CameraHardware::supportedPreviewSizes [] = "640x480,352x288,320x240";
const supported_resolution CameraHardware::supportedPictureRes[] = {{640, 480} , {352, 288} , {320, 240} };
const supported_resolution CameraHardware::supportedPreviewRes[] = {{640, 480} , {352, 288} , {320, 240} };
typedef struct {
size_t width;
size_t height;
} supported_resolution;
I see! You could try having a look at the stack to identify the caller hierarchy up to the JNI, and also in IDA Pro check the xref to the function. At some point the values will be generated. It is possible that the string itself is constructed from an array of dwords, so checking for the little-endian hexadecimal dwords in the .so could be useful.
Regarding structs, it might be easier to identify them in IDA Pro, however I'm not sure it is possible to create a struct type in gdb (by default it will use the symbols, but for proprietary libs there are none...).
Note there is support for gdbserver in IDA Pro, which allows you to trace the code you have annotated. It is much nicer than the text interface of gdb, however the gdb client plugin in IDA can be flaky at times. Note that in this case, you'll want to loader mediaserver then load any additional .so in IDA to be able to trace them all. In addition, it would be a good idea to disable ASLR (IDA Pro doesn't handle library randomization too well). Run "echo 0 > /proc/sys/kernel/randomize_va_space"
Thank you again for all useful info!
It seems that strings are built by some "string" functions, so I think you are right, but it's a bit hard with static analysis.
Now I'm trying to connect IDA Pro with gdb, but I'm stuck with a connection error:
Plan B: I can remove lib checks when setting parameters, but it's an hacky solution, I prefer clean solutions...
EDIT: I missed "adb forward tcp:1234 tcp:1234" :/
now i got "irs_recv: Timeout" error
EDIT 2: Attached! (switched from arm/android debugger to gdb)
EDIT 3: I don't know how to set breakpoint, if I try to set with F2, process never stops, if I try to set it via console i got an error...
pirlano said:
Thank you again for all useful info!
It seems that strings are built by some "string" functions, so I think you are right, but it's a bit hard with static analysis.
Now I'm trying to connect IDA Pro with gdb, but I'm stuck with a connection error:
Plan B: I can remove lib checks when setting parameters, but it's an hacky solution, I prefer clean solutions...
EDIT: I missed "adb forward tcp:1234 tcp:1234" :/
now i got "irs_recv: Timeout" error
EDIT 2: Attached! (switched from arm/android debugger to gdb)
EDIT 3: I don't know how to set breakpoint, if I try to set with F2, process never stops, if I try to set it via console i got an error...
Click to expand...
Click to collapse
Glad to know! I'll write a short tutorial of gdbserver +IDA a bit later using mediaserver as an example, in two different cases: first one with symbols, second out without.
xd.bx said:
Glad to know! I'll write a short tutorial of gdbserver +IDA a bit later using mediaserver as an example, in two different cases: first one with symbols, second out without.
Click to expand...
Click to collapse
Alright, so I'm running into the same issue when trying to trigger a breakpoint and trace stuff. On the other hand gdb works fine. /methink IDA Pro's internal gdb client is not that good. In fact it would be rather nice to have an open-source replacement for this piece of software, one that makes stepping through proprietary code less of a chore.
Hello friends, I'm back again with something I wish to share with you all. I have compiled three files to work flawlessly for ARM devices which will allow users to unpack, edit, and repack their boot.img without the use of a PC and all straight from their device.
---unmkbootimg, mkbootfs, mkbootimg---
Click here for the source on my Github.
Hey guys, since I have made this thread a while back there has been a LOT of changes made to the resource. For starters, it is now a multi call binary. In addition, I have updated mkbootfs for better support, mkbootimg.c has dt support, unmkbootimg.c has dt support, bootimg.h has dt support, as well as adding dtbtool, and dtc. Lets not also forget about lz4 for those whos ramdisks are not gz compressed. I am continuously making changes to the source and the op attachment will not be kept up to date. To stay up to date you will need to build the multi call binary from the source provided by the link above. Just simply run: make multi.
Note:
-- The mkbootimg binary is based upon the AOSP with some added modifications to work in conjunction with unmkbootimg.
-- The unmkbootimg binary is based on the original mkbootimg source but with reverse engineering to compliment its helpful use in extraction and thus providing the needed command to rebuild properly.
-- The mkbootfs binary is based on the source provided within the dsixda kitchen to insure the proper structural repacking of the ramdisk, etc.
Requirements:
-- BusyBox (cpio, gunzip and gzip is mandatory)
-- /System Write Permissions (Does not need to be a modified kernel)
-- Terminal Emulator
-- ES File Explorer (or similar)
-- Hex Editor (or use of DD)
-- Unzip boot_manipulation.zip on your device and copy the three files over to /system/bin. Those three files inside the .zip will be named unmkbootimg, mkbootfs and mkbootimg.
-- EDIT: I have included a flashable zip for these files.
-- Set permissions to rwxr-xr-x (755) on each binary. Note: The flash zip does this already.
-- Open up your android terminal emulator.
-- Now go ahead and pull your boot.img from your device (or use another one if you wish). Here is an example:
Code:
[email protected]:/ # [COLOR="Red"]dd if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img[/COLOR]
dd if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img
32768+0 records in
32768+0 records out
16777216 bytes transferred in 1.496 secs (11214716 bytes/sec)
[email protected]:/ #
-- Open up your boot.img with the Hex Editor and look for: ANDROID!. Remove everything before it so that the ANDROID! header is the first to be read then save it over top of the boot.img. NOTE: This is only required if you are using a stock boot.img. Here is an example:
Code:
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 [COLOR="red"]A5 F0 BA B7 B0 43 E3 F8 3C E1 63 55 AE 75 C6 69 ¥ðº·°Cãø<ácU®uÆi[/COLOR]
00000010 [COLOR="red"]11 27 16 2F 51 48 E5 41 6F ED E1 7D C9 61 FB 3B .'./QHåAoíá}Éaû;[/COLOR]
00000020 [COLOR="red"]5F 45 49 EE 48 79 6E 4E FB DE 18 FC A0 F4 9A C3 _EIîHynNûÞ.ü*ôšÃ[/COLOR]
00000030 [COLOR="red"]43 11 35 67 AD 7E 2F D8 F6 E8 B1 4D 7D E0 45 B6 C.5g.~/Øöè±M}àE¶[/COLOR]
00000040 [COLOR="red"]E2 08 5F 0B 56 7F 45 71 3D 38 E2 C4 76 3E 53 EE â._.V.Eq=8âÄv>Sî[/COLOR]
00000050 [COLOR="red"]A4 3D 83 9F A2 BE D5 F4 75 5D B5 08 4E CC 9B BC ¤=ƒŸ¢¾Õôu]µ.NÌ›¼[/COLOR]
00000060 [COLOR="red"]7F 7A 9E 3D 4B 19 1B 91 6D FB 82 A0 B5 A8 38 88 .zž=K..‘mû‚*µ¨8ˆ[/COLOR]
00000070 [COLOR="red"]25 07 B5 1B 74 A2 03 62 BE 78 FA 33 96 A0 32 70 %.µ.t¢.b¾xú3–*2p[/COLOR]
00000080 [COLOR="red"]05 56 50 EF 88 C1 F3 73 E4 C5 73 6A 4E F8 CA 0A .VPïˆÁósäÅsjNøÊ.[/COLOR]
00000090 [COLOR="red"]D7 EF 2A 7F 09 30 21 BF 63 61 35 9A 9B 8A 62 42 ×ï*..0!¿ca5š›ŠbB[/COLOR]
000000A0 [COLOR="red"]28 C2 78 08 B0 CD 94 5F 7E EC F6 BA AD E6 AE 23 (Âx.°Í”_~ìöº.æ®#[/COLOR]
000000B0 [COLOR="red"]3E FD D8 A0 F1 F6 6D E2 D9 1E 2C E5 9F 91 84 92 >ýØ*ñömâÙ.,埑„’[/COLOR]
000000C0 [COLOR="red"]2E F0 6E 3C 1D 2B 1A D5 61 18 B2 F4 E0 66 B5 2F .ðn<.+.Õa.²ôàfµ/[/COLOR]
000000D0 [COLOR="red"]AE 97 9F F8 53 65 CE ED 68 43 4B 2B D5 A1 B6 D9 ®—ŸøSeÎíhCK+Õ¡¶Ù[/COLOR]
000000E0 [COLOR="red"]7D 36 CE A9 CC EC F4 5A 07 D8 99 5A 91 CC 8F 71 }6ΩÌìôZ.Ø™Z‘Ì.q[/COLOR]
000000F0 [COLOR="red"]A1 8D D7 82 C3 20 AB 7A 07 68 10 2D CC F6 A8 F9 ¡.ׂà «z.h.-Ìö¨ù[/COLOR]
00000100 41 4E 44 52 4F 49 44 21 08 D6 56 00 00 80 40 80 ANDROID!.ÖV..€@€
00000110 0E F0 07 00 00 80 80 81 00 00 00 00 00 00 30 81 .ð...€€.......0.
00000120 00 01 40 80 00 08 00 00 00 00 00 00 00 00 00 00 [email protected]€............
00000130 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
-- Please note, HTC uses a 256 bit signature prior to the ANDROID! magic found in the boot.img. This may vary with other devices so keep that in mind. To remove the 256 bit junk so the boot.img is read properly you can use a hex editor and delete it or you can use DD. The following dd command I will be using is based on K2_CL in regards to the partition for our boot.img. Please make necessary adjustments to this command by insuring you know the location and where abouts of your own boot.img; Example:
Code:
dd bs=256 skip=1 if=/dev/block/mmcblk0p20 of=/data/local/tmp/boot.img
-- Alright, so we have the unmkbootimg, mkbootfs and mkbootimg located in /system/bin. We have pulled our boot.img and removed the junk before the magic android value: ANDROID!. Let's continue.
-- Go back to your android terminal emulator and change directories to /data/local/tmp. Here is an example:
Code:
[email protected]:/ # [COLOR="red"]cd /data/local/tmp[/COLOR]
cd /data/local/tmp
[email protected]:/data/local/tmp #
-- Now run unmkbootimg. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]unmkbootimg -i boot.img[/COLOR]
unmkbootimg -i boot.img
kernel written to 'kernel' (5690888 bytes)
ramdisk written to 'ramdisk.cpio.gz' (521735 bytes)
To rebuild this boot image, you can use the command:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80408000 --ramdisk_offset 0x81808000 --second_offset 0x81300000 --tags_offset 0x80400100 --cmdline 'console=ttyHSL0,115200,n8 user_debug=31' --kernel kernel --ramdisk ramdisk.cpio.gz -o boot.img
[email protected]:/data/local/tmp #
-- Before you go any futher, copy all text within your android terminal emulator and paste it in to a text document. I personally use 920 Text Editor from the play store. You will do this so when the time comes you can open it back up and copy/paste the command to rebuild your boot.img as listed (This will save you some time).
-- Congratulations, you have done well so far. By typing and entering the command 'ls', you can see what all is in your directory. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]ls[/COLOR]
ls
boot.img
init.rc
kernel
ramdisk.cpio.gz
[email protected]:/data/local/tmp #
-- Now lets create a folder and lets call it ramdisk. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]mkdir ramdisk[/COLOR]
mkdir ramdisk
[email protected]:/data/local/tmp #
-- Now lets change directories to that ramdisk folder. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]cd ramdisk[/COLOR]
cd ramdisk
[email protected]:/data/local/tmp/ramdisk #
-- Go ahead and extract ramdisk.cpio.gz. Here is an example:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="red"]gunzip -c ../ramdisk.cpio.gz | cpio -i[/COLOR]
isk.cpio.gz | cpio -i <
1851 blocks
[email protected]:/data/local/tmp/ramdisk #
-- Congratulations, you have done well so far. By typing and entering the command 'ls', you can see what all is in your directory. Here is an example:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="red"]ls[/COLOR]
ls
cwkeys
data
default.prop
dev
fstab.k2_cl
init
init.goldfish.rc
init.qcom.rc
init.qcom.sh
init.rc
init.target.rc
init.target.recovery.rc
init.trace.rc
init.usb.rc
proc
sbin
sys
system
ueventd.goldfish.rc
ueventd.rc
ueventd.target.rc
[email protected]:/data/local/tmp/ramdisk #
-- Now feel free at this point to make your edits within the ramdisk folder. When complete then come back and we shall finish the job.
-- Go ahead and move back out of the ramdisk folder by the following command:
Code:
[email protected]:/data/local/tmp/ramdisk # [COLOR="Red"]cd ..[/COLOR]
cd ..
[email protected]:/data/local/tmp #
-- You should now be in /data/local/tmp/.
-- Lets go ahead and repack the contents found in the ramdisk folder. Here, we will make use of the mkbootfs binary. Please take note that your original is named 'ramdisk.cpio.gz'. Here we will be repacking and renaming it to 'myramdisk.gz'. Here is an example:
Code:
[email protected]:/data/local/tmp # [COLOR="red"]mkbootfs ./ramdisk | gzip > myramdisk.gz[/COLOR]
mkbootfs ./ramdisk | gzip > myramdisk.gz
[email protected]:/data/local/tmp #
-- Open up your saved text file as instructed earlier and scroll to where you see this:
Code:
To rebuild this boot image, you can use the command:
mkbootimg --base 0 --pagesize 2048 --kernel_offset 0x80408000 --ramdisk_offset
0x81808000 --second_offset 0x81300000 --tags_offset 0x80400100 --cmdline 'conso
le=ttyHSL0,115200,n8 user_debug=31' --kernel kernel --ramdisk ramdisk.cpio.gz -o
boot.img
-- Look for --ramdisk ramdisk.cpio.gz and INSURE you change it to --ramdisk myramdisk.gz. Also go ahead and change boot.img to modboot.img. Now copy the mkbootimg command and paste it in to your android terminal emulator. Press enter.
-- There are multiple ways you can apply the new boot.img. The smartest way would be to use fastboot so that you may boot the image vice flashing it in case you screwed something up on your own accord. However, I personally will write the boot.img straight to the boot partition using dd, then I reboot the device. If you wish to do the same then that is fine.
-- Now you have your new Modded Boot Image. Enjoy, and as always... CLICK THANKS if this was helpful to you and....
--- Happy Hunting!!!
MKBOOTIMG-TOOLS
GITHUB SOURCE:
https://github.com/ModdingMyMind/mkbootimg_tools
Original Author: xiaolu (GITHUB SOURCE: https://github.com/xiaolu/mkbootimg_tools)
Heavily Modified By: @Modding.MyMind
This project is originally based from xiaolu. To make this compatible for ARM I modified the script, compiled some binaries such as file, bash, grep, gzip, lzma, xz, mkbootimg, etc.
-- This project uses busybox but due to how stripped and limited busybox is ultimately led to me having to compile a few binaries from source. These binaries must be part of the project in order for the project to be succesfull. For example, busybox grep will not always give accurate offsets for the android header. One of MANY bugs found with busybox.
This project supports device tree binaries found inside the Boot.img and Recovery.img.
This project supports multiple Ramdisk compressions.
-- This project will check the ramdisk compression and if it determines that the tool does not support that particular compression then it will display a hazard warning letting the user know that the compression is not supported and that the ramdisk currently cannot be decompressed or compressed until support has been officially added.
-- If the compression is supported it will display what type of compression the Ramdisk is and how many blocks it has when unpacked.
This project will determine your kernel size, ramdisk size, and TRUE OFFSETS (not just the standard mkbootimg.c offsets).
-- With respect to the offsets; You will learn that many available tools found available specifically handle images where the ANDROID! header is located at 0x0. Not all images are built like this from stock. This project will find the header, base, kernel offset, ramdisk offset, second offset, and tags offset. It will rebuild the image using DD to insure the android header is located at 0x0. The found offsets inside the image will be cross referenced to see if the OEM of that image built it using the standard mkbootimg.c. If it detects any offsets which are built using NON-standard offsets then it will display a warning as well as show you what the image TRUE offsets actually are. Those same offsets are then applied to properly rebuild your image to insure that it boots like it was intended to do.
-- The warning will let you know that you may modify mkbootimg.c with the NON-standard values if you wish to have a binary specific to your device. The offsets displayed are not the address. Because the offsets are determined and not the address this makes it possible for this project to not have to rebuild mkbootimg.c. When the project is used to rebuild your image using the mkbootimg args such as --ramdisk_offset, --kernel_offsets, etc, etc, this then tells mkbootimg.c to ignore the hardcoded offsets and only use the ones it has been instructed to use. This is even more successful by insuring the BASE is accurate and applying the base as one of the mkbootimg args (--base 0 <-- this is lazy and stupid).
The mkboot script requires two args whether unpacking the image or repacking the image.
-- mkboot boot.img bootfolder (This will unpack the image)
1. mkboot is the script.
2. boot.img is the actual image.
3. bootfolder will be created and become the project folder.
-- mkboot bootfolder newboot.img (This will repack the image)
1. mkboot is the script.
2. bootfolder is the project folder which has the needed files and information to repack.
3. This will be the name of the finished build.
UNPACK STANDARD IMAGE
This image uses standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot.img work
Unpack & decompress boot.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 2529072
ramdisk size : 230255
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Ramdisk is lzma format.
1436 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK STANDARD IMAGE
Image repacked with standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.lzma
page size : 2048
kernel size : 2529072
ramdisk size : 230029
base : 0x12200000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : mem=471M console=ttyMSM2,115200n8 androidboot.hardware=thunderc lge.rev=10
Kernel size: 2529072, new ramdisk size: 230029, boot.img: 2762752.
boot.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK NON-STANDARD IMAGE
This image uses non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot recovery.img work
Unpack & decompress recovery.img to work
****** WARNING ******* WARNING ******* WARNING ******
This image is built using NON-standard mkbootimg!
RAMDISK_OFFSET is 0x01608000
You can modify mkbootimg.c with the above value(s)
****** WARNING ******* WARNING ******* WARNING ******
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 5834192
ramdisk size : 4351685
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Ramdisk is gzip format.
14837 blocks
Unpack completed.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK NON-STANDARD IMAGE
Image repacked with non-standard mkbootimg.c:
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work recovery.img
mkbootimg from work/img_info.
kernel : zImage
ramdisk : new_ramdisk.gzip
page size : 2048
kernel size : 5834192
ramdisk size : 4358038
base : 0x80600000
kernel offset : 0x00008000
ramdisk offset : 0x01608000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 user_debug=31
Kernel size: 5834192, new ramdisk size: 4358038, recovery.img: 10194944.
recovery.img has been created.
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
UNPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot boot-1.img work
Unpack & decompress boot-1.img to work
kernel : zImage
ramdisk : ramdisk
page size : 2048
kernel size : 3580032
ramdisk size : 594701
base : 0x10000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
second_offset : 0x00f00000
tags offset : 0x00000100
cmd line :
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't unpack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
REPACK IMAGE WITH INCOMPATIBLE RAMDISK
[email protected]:/data/local/tmp/mkbootimg_tools-master # ./mkboot work boot-1.img
mkbootimg from work/img_info.
****** HAZARD ******* HAZARD ******* HAZARD ******
Ramdisk is data format. Can't repack ramdisk.
This tool currently does not support data.
****** HAZARD ******* HAZARD ******* HAZARD ******
[email protected]:/data/local/tmp/mkbootimg_tools-master #
Click to expand...
Click to collapse
mkbootimg updated in .zip file. Enjoy
I went through some mess to get it to work correctly lol.
Works like a champ now.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
mkbootimg updated in .zip file. Enjoy
I went through some mess to get it to work correctly lol.
Works like a champ now.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Did you compiled mkbootimg?
Please can you say me in detail the not-booting problem? It rebooted continuously between bootloader and bootanimation?
xpirt
xpirt said:
Did you compiled mkbootimg?
Please can you say me in detail the not-booting problem? It rebooted continuously between bootloader and bootanimation?
xpirt
Click to expand...
Click to collapse
Yea, I compiled it. The last one I compiled wasnt done correctly. The sha and rsa was corrupted. But I fixed it.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
Yea, I compiled it. The last one I compiled wasnt done correctly. The sha and rsa was corrupted. But I fixed it.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
I understand. And the bootloop I said is exactly what happened when packed with old mkbootimg?
xpirt
@xpirt
No bootloop. It would boot once and show the splash screen. Then reboot straight in to the custom recovery. Basically what happen in the old mkbootimg was the source code having too many white spaces and some other syntax issues. I had to go through every single command line in every single file to fix it. Spent almost 15+ hours reworking the codes. Then I compiled it, placed it on my device in /data/local/tmp. Pulled my boot img from my partition using dd over to /data/local/tmp. Ran the steps to unpacking, editing, and then used the new mkbootimg to repack it. After completion I wrote the new boot.img over to the partition using dd. Then rebooted, worked flawlessly without any bugs, errors, or hiccups.
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
@xpirt
No bootloop. It would boot once and show the splash screen. Then reboot straight in to the custom recovery. Basically what happen in the old mkbootimg was the source code having too many white spaces and some other syntax issues. I had to go through every single command line in every single file to fix it. Spent almost 15+ hours reworking the codes. Then I compiled it, placed it on my device in /data/local/tmp. Pulled my boot img from my partition using dd over to /data/local/tmp. Ran the steps to unpacking, editing, and then used the new mkbootimg to repack it. After completion I wrote the new boot.img over to the partition using dd. Then rebooted, worked flawlessly without any bugs, errors, or hiccups.
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Ok. Good, I'll try it out
xpirt
xpirt said:
Ok. Good, I'll try it out
xpirt
Click to expand...
Click to collapse
Sounds good. If it is a stock boot.img then you will need to remove everything before the android magic value (ANDROID!). After that, have at it lol. I will be adding additional code later on that will automatically look for the android magic value and make the necessary changes to it so it reads properly. This will keep others from having to do it themselves. Until then, has to be done by the user since I have hard-coded the magic android value.
Sent from my K2_CL using Tapatalk
Also plan to edit the unpackbootimg file so it will automatically extract the ramdisk archive automatically with out the need of the user having to use the ramdisk.sh file or by manually inputing the commands to do so. Got other plans as well. So a lot of improvements and bonuses are to come. Gonna try and make this thing a beast for arm devices.
Sent from my K2_CL using Tapatalk
OP updated with more in depth instructions/examples. Also, I have taken out the ramdisk.sh file and have also removed the unpackbootimg file. I have implemented unmkbootimg and a remake of the mkbootimg file(s). Works like a boss and gives you all the information you need to rebuild your boot.img. Will work on ALL arm devices. Enjoy.
Added download link to open source. See OP.
Sent from my K2_CL using Tapatalk
OP has been updated. I have included an additional binary called mkbootfs to work in conjuction with the other two given the necessary structural building properties of the boot.img. I have tested this on A LOT of boot.img's and all have been successful. I have also updated the instructions for using these binaries on your android device. Enjoy.
sweet sweet victory!
russellvone said:
sweet sweet victory!
Click to expand...
Click to collapse
This project was a pain bro. I almost gave up on it. Was dancing on thin ice until I had a break through which pushed me to complete the task. Works beautifully now .
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
This project was a pain bro. I almost gave up on it. Was dancing on thin ice until I had a break through which pushed me to complete the task. Works beautifully now .
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
This is awesome.
Can you share the source code for this?
Sent from my GT-I8730 using Tapatalk
PM Sent
Sent from my K2_CL using Tapatalk
Modding.MyMind said:
PM Sent
Sent from my K2_CL using Tapatalk
Click to expand...
Click to collapse
Thank you!
Sent from my GT-I8730 using Tapatalk
OP updated with four photo attachments.
Sent from my K2_CL using Tapatalk
(Probably n00bish) Question:
How do I compile the binaries from the source? By gcc or make?
Beamed from my Galaxy Express using Tapatalk