Develop Bugs

How to reconstruct a binary identical I9000XWJP6 kernel image, and more

The idea of this exercise is (at least) to get a stable starting point for kernel development. The thing which is currently missing is a proper working .config. I have reconstructed it using differential analysis and in the process hoped to find which components have actually been activated and to uncover changes (or Easter eggs) in the sources which have not been advertised. Having a working and identical I9000XWJP6 kernel also means that open development can continue from the current official public release. From there the things possible are only limited by your imagination.
The following is a walk-through on how to build the kernel, description of pitfalls that will cause changes in .config to break, and some annotations on discoveries made in the process.
The things you need are:
Mandatory:
- I9000XWJP6 zImage : from your favorite location
- Source tree : opensource•samsung•com the GT-I9000 OpenSource Froyo Update JPM.zip
- Sourcery G++: www•codesourcery•com/sgpp/lite/arm/portal/release1039
- Tweak-Kit : <attached>
Optional:
- Arm enabled GCC and binutils, including a development libbfd.
- Lots of your favorite beverage
The md5sum of the zImage should be: 26e9d5d206baf1515144c6b8de6f10d2
It is critical that the Sourcery G++ version is 2009q3-67.
The Tweak-Kit contains the following components:
Readme.txt - You're reading it
mkvmlinux.cc - convert zImage to vmlinux and extract the init ramdisk image
I9000XWJP6_defconfig - default .config
stamp.patch - set date/time and such to original
style.patch - fix style related warnings
prototype.patch - fix prototype related warnings
error.patch - Recoverable errors
houston.patch - Unrecoverable errors
shadow.patch - Fixate data structures
I9000XWJP6.h - Fixated macros
I9000XWJP6.c - Entry point stubs
SOME THINGS I ENCOUNTERED IN THE PROCESS:
a) What I absolutely did not expect was that I found two different encodings of the build timestamp. I could deduce that the timezone was central Europe. I had the assumption it would be Asia or America.
b) What was to be expected is that the source tree is incomplete. The directories drivers/fsr and fs/rfs are missing. You can still compile the kernel as the missing files are used to build modules. Problems start when you change the config. Doing so will change entry points and data structures and your kernel might die a horrible death when it loads modules who are unaware on these changes. There is a workaround which I will explain later.
c) The weirdest thing I encountered were the functions enable_hlt() and disable_hlt(). The are located deep in the unwind tables, a section not intended for code. I spent many hours trying to figure out how they got there or why but I still have no clue. I found exactly only one way to reproduce this behaviour and it is certainly not due to a typo, accident or ignorance.
d) The kernel is not a production but a debug version. It has nearly all tracking/tracing/debug bells and whistles switched on. If the energy required to maintain the statistics where to emit light, you could use your Galaxy as a Christmas tree. Function profiling is enabled and has a considerable negative effect on performance, code is not optimized for size but speed, and unwind tables have been enabled which are not used. These have a really bad impact on footprint size. I really hope that the same compiler and settings are not used for the Android layer. Changing the config into a production version will not work (and crash) as the non-native modules expect the debugging hooks which will no longer exist. But the same workaround as above can be used.
e) The functionality of the power management domains have been optimized to oblivion due to the excessive placing of code disabling comments in large parts of the clock, power management and mach-aries.c. Maybe because the Galaxy hardware is too different than the evaluation boards, or the hardware is buggy and disabling the code makes it less unstable, or there was just not enough time to get the code working. Anyway, at this moment I have no oversight into what degree the absence of power domains influence battery usage.
f) When I started examining the binary code I was puzzled by snippets of code I could not reproduce. Even worse, I encountered snippets that were just questionable. Unusual instruction sequences, and resister usage. Thinking I bumped into a GCC bug, I started debugging the compiler and even tweaked instruction scheduling weights but with no satisfying outcome. I know that GCC is very stubborn with regard to saving and clobbering registers in/across function calls and the code I saw was just incorrect. I knew a different compiler was used and I suddenly realized that it may be more different than what first meets the eye. The culprit turned out to be Sourcery G++. It is a private maintained branch of GCC for reasons I have not investigated. Even the Sourcery assembler is tainted as it played a nasty trick on me with the enable_hlt/disable_hlt thing. I do not like the code I see and I am aiming into getting the sources stock GCC friendly with a working kernel. However, GCC and Sourcery generate code which seem difficult to mix, but I'm getting closer.
g) Compiler warnings. Many of the Samsung sources generate warnings, something I really dislike. In my opinion a warning is emitted for a piece of code which can be interpreted in several ways, leaving the compiler to choose which. Usually it will choose the wrong one. Most warnings were related to coding style shortcuts, a couple of incorrect function prototype resulting in functions that should return int to return random or falsely ignoring return values. There were also a couple of nasties like deference of uninitialized pointers, accessing out-of-bound data and mixing clock data-structures of different types. Included are a number of patches to fix them.
h) I looked deeper into why GCC and Sourcery won't mix and discovered that they have different implementations with regard to constant definition within enum declarations. Google points to the staring point "GCC bug 30260" where is written that the behaviour of enumeration constants has changed to becoming signed int. I have noticed that even explicit unsigned values will change to signed.
Here is an example of what is going wrong:
Take following declaration
Code:
enum rt_class_t { RT_TABLE_MAX=0xFFFFFFFF }
. GCC will consider RT_TABLE_MAX to be -1, and Sourcery will consider it 4294967295. Now, in net/ipv4/fib_rules.c there is this code snippet
Code:
for (u32 id = 1; id <= RT_TABLE_MAX; id++)
GCC will skip the loop, and Sourcery will have a hard time doing nothing.
There are more examples like calculating the location of physical memory or signed/unsigned comparisons. The compiler switches -fwrapv and -fstrict-overflow might influence things, but it general the behaviour is hardcoded and both compilers have a different flavour. I think it would be wiser to choose the GCC flavour as it is more widespread and thus better tested (and fixed).
i) GCC. I noticed that early versions of kernels compiled with GCC would not start. At first I thought it was because of Sourcery /GCC code generating differences. After a number of buxfixes (in error.patch) I suddenly noticed that the GCC kernel is working. My phone is running a GCC compiled production configured kernel for nearly a week.
j) "Houston, we've had a problem" with the light sensor. One of the compiler warnings brought me to the file drivers/sensor/optical/gp2a.c. There within are located two routines which read the light and proximity sensor. They seem copy-pasted identical, however the sensor value types are different as the proximity value is a char and the light intensity a double. What is more convenient than to simply change the data type of the supplied buffer in the function prototype. Now headache starts as the semantics of the read (and write) call say that the unit size is byte. So returning "1" indicates that only the first byte of the sensor value is copied. Also, there is no bounds/access checking so supplying an invalid pointer to the call will crash the kernel. So, assuming this is all one big mistake, I redesigned the function to do better (see houston.patch) and built a new kernel with it. To my utter surprise my battery charge extended from <24 hours to 2 days and 20 hours.
However... I also noticed that my backlight intensity level was constant at it's lowest although the setting was set to auto. I needed to know how the caller invokes the call, but after an extensive search of internet and android sources it is still something I have not found. Heuristics show that the reading the light sensor is called with a buffer length of 1, and the returned value is only accepted when returning a 1 and that the sensor value type is a double (8 bytes). This is wrong: read() semantics require that you supply a length of 8, and expect a return value of 8. This may be the base of many light sensor issues I found when Googling.
Anyway, I returned the code to it's original faulty behaviour, and being illuminated I disabled the auto backlight intensity and changed it to it's lowest setting to enjoy a longer life between battery charges.
TO CREATE YOUR KERNEL:
1) Prepare a working environment
1a) Unpack Sourcery G++. No installation needed, unpacking is sufficient
1b) Unpack the Samsung sources and cd to the location of the top-level Makefile.
1c) Unpack the zImage and the contents of the Tweak-Kit to the same location
1d) Make sure the zImage is called zImage.I9000XWJP6
2) The ramdisk image is required and can be extracted from zImage.I9000XWJP6
2a) Create an uncompressed image Image.I9000XWJP6
Code:
gcc scripts/binoffset.c -o scripts/binoffset
ofs=`scripts/binoffset zImage.I9000XWJP6 0x1f 0x8b 0x08 0x00 2>/dev/null`
dd ibs=$ofs skip=1 <zImage.I9000XWJP6 | gzip -c -d >Image.I9000XWJP6
2b) The Tweak-Kit includes mkvmlinux which converts the uncompressed binary image into a bfd object. You need an Arm enabled libbfd to get it working. This does not get installed by default so you need to deeplink into binutils. mkvmlinux locates and decodes the kallsym data and econstructs the symbol table. It then uses the values of __initramfs_start/end to extract the initramfs. If you are not bothered with the hassle, just use dd with hardcoded values.
Code:
g++ mkvmlinux.cc -o mkvmlinux -lbfd -liberty -lz [-I and -L that deeplink into binutils]
./mkvmlinux Image.I9000XWJP6 vmlinux.I9000XWJP6 -r initramfs.cpio
or
Code:
dd if=Image.I9000XWJP6 of=initramfs.cpio bs=1 count=2739712 skip=165568
3) Patch date/time and other environmental issues to the moment of original creation
Code:
patch -p1 <stamp.patch
4) Make your computer happy
Code:
# edit Makefile line 184 and update the macro CROSS_COMPILE=
cp I9000XWJP6_defconfig arch/arm/configs/I9000XWJP6_defconfig
make I9000XWJP6_defconfig
make
5) Verify that the kernel is identical
Code:
diff zImage.I9000XWJP6 arch/arm/boot/zImage
AND NOW FOR SOMETHING COMPLETELY DIFFERENT...
Tweaking the configuration will build you a new kernel but when your Galaxy powers on it will either die silently (hang) or experience a horrible death (reboot). The problem is that there are modules built from sources located in the removed directories drivers/fsr and fs/rfs. These modules were compiled with a specific data structure layout and entry points. These will surely change when re-configuring. The way to keep the non-native modules happy is to keep the structures and entry points intact.
The structure layout is influenced by the CONFIG_ macros. The structures can be fixed to reflect the state of the I9000XWJP6 kernel by replacing the CONFIG_ macro's by something that does not change after reconfiguration. For that I use a collection of 'shadow' macro's which have SHADOW_ as prefix. Because the data structures cannot expand, you cannot (easily) enable configure functionality which require extra fields in the data structures. Reducing functionality is highly seldom a problem.
If changing kernel functionality results in removal of entry points, then stubs are required for those entry points needed by the non-native modules
There are automated methods to verify that a new kernel abides to the above constraints. For the data structures the compiler must generate gstabs debug information. This is human readable and includes detailed structure descriptions. This information should be identical across re-configuration. However, the scripts get confused by anonymous structs which are by product of "typedef struct {" constructions. These need to be named, something shadow.patch also does.
The kernel modules have easily-readable symbol tables containing needed kernel entry points. These should all be present in all re-configured kernels. Validation tests that fail emit enough information to further fix data structures and entry points. The Tweak-Kit contains two files: I9000XWJP6.h containing the SHADOW_ macro's and I9000XWJP6.c for the stubs. Both were constructed in an on-demand basis for the reconfiguration I am currently using and both serve as good examples on what to do when validation fails.
Before reconfiguring, rebuild the kernel for usage as a validation checkpoint.
1) Undo the timestamp patches
Code:
patch -R -p1 <stamp.patch
2) Fix the warnings
Code:
patch -p1 <style.patch # style related issues
patch -p1 <prototype.patch # prototype related issues
patch -p1 <error.patch # bug fixing
3) Apply datastructure fixation, entrypoint stubbing and Makefile tweaking
Code:
patch -p1 <shadow.patch
cp I9000XWJP6.c arch/arm/plat-samsung
4) Before recompiling everything, you need to issue "make clean" first. However, the missing directories will now pose a problem as "make clean" will include their Makefiles and will fail if it can't. Just create empties to keep the build happy.
Code:
mkdir -p drivers/fsr fs/rfs
touch drivers/fsr/Makefile fs/rfs/Makefile
5) Optionally change the Makefile to point to your favorite compiler/toolchain. Please note that I am using GCC 4.4.5. GCC 4.5.1 is bumping into problems I haven't looked into yet.
Code:
# edit Makefile line 184 and update the macro CROSS_COMPILE
6) This build will generate gstab debug information. Unexpectingly, this might bite when combined with function profiling, so disable that. But do not CONFIG_FUNCTION_TRACER yet as that does more.
Code:
# edit Makefile line 553, disable the line containing KBUILD_CFLAGS += -pg
7) Unpack the initramfs image. The directory /lib/modules needs to be examined/updated
Code:
mkdir initramfs.dir
cd initramfs.dir
cpio -i --make-directories --preserve-modification-time --no-absolute-filenames <../initramfs.cpio
cd ..
8) Repack initfs as a tarball, as make clean will erase all the modules
Code:
tar cf initramfs.tar initramfs.dir
9) The initramfs image will contain new kernel modules. Make sure a new version will get generated.
Code:
# in .config line 80 point to the unpacked initram location
CONFIG_INITRAMFS_SOURCE="initramfs.dir"
# in .config lines 86-89, select your favourite compression
CONFIG_INITRAMFS_COMPRESSION_NONE=N
CONFIG_INITRAMFS_COMPRESSION_GZIP=Y
10) Build a new kernel
Code:
# not cleaning will confuse the verification
make clean
make CONFIG_DEBUG_INFO=y
# install the modules
tar xf initramfs.tar
cp `find drivers -name '*.ko'` initramfs.dir/lib/modules
# rebuild with a fresh new ramdisk image
rm usr/initramfs_data.cpio*
make CONFIG_DEBUG_INFO=y
11) Checkpoint structure/entrypoint information. This is architecture independent.
Code:
# extract structures. They are the entries with :T
objdump -G vmlinux | awk '{ print $7 }' | grep :T | sed 's/([^)]*)/()/g' | sed 's/=\*()//g' | sort -u > gstabs.ckp
# extract the entrypoints
nm vmlinux | grep 'r __ksymtab_' | awk '{ print $3 }' | sort > ksymtab.ckp
12) Do a test-run. Pack zImage and flash with Odin. If your Galaxy is up and running, I strongly suggest you make a backup of your environment. If you later change something and it breaks, then this is the best place to restart.
Code:
cp arch/arm/boot/zImage .
tar cf I9000XWJP6-2.6.32.9-test.tar zImage
13) Make your re-configuration. I really suggest you do not make too many changes in one go because it gives more work when the structure/entrypoint verification fails.
Code:
# re-configure. For this exercise, change the kernel to a more production version
CONFIG_CC_OPTIMIZE_FOR_SIZE=Y
CONFIG_DM_DEBUG=N
CONFIG_S3C_KEYPAD_DEBUG=N
CONFIG_DEBUG_FS=N
CONFIG_DEBUG_KERNEL=N
CONFIG_LATENCYTOP=N
CONFIG_FTRACE=N
CONFIG_ARM_UNWIND=N
CONFIG_DEBUG_USER=N
14) Build a new kernel
Code:
# not cleaning will confuse the verification
make clean
make CONFIG_DEBUG_INFO=y
# install the modules
tar xf initramfs.tar
cp `find drivers -name '*.ko'` initramfs.dir/lib/modules
# rebuild with a fresh new ramdisk image
rm usr/initramfs_data.cpio*
make CONFIG_DEBUG_INFO=y
You get "struct has no member named" errors if you have enabled subsystems that require data structures to change which are incompatible with the non-native modules.
15) Verify structure/entrypoint checkpoint
Code:
# extract/verify structures
objdump -G vmlinux | awk '{ print $7 }' | grep :T | sed 's/([^)]*)/()/g' | sed 's/=\*()//g' | sort -u > gstabs.t
# new/changed structures are tagged with '+'. Display only the changed ones
diff -U0 gstabs.ckp gstabs.t | grep '+' | grep ':T' | sed 's/+//' | sed 's/:T.*/:T/' | while read s; do
grep -q "$s" gstabs.ckp
if [ $? -eq 0 ]; then
echo $s;
fi
done
# extract/verify entrypoints
nm vmlinux | grep 'r __ksymtab_' | awk '{ print $3 }' | sort >ksymtab.t
# extract all entrypoints needed by the modules
nm `find initramfs.dir/ -name '*.ko'` >allkosym
# some symbols are referenced in other modules. Cross-reference and remove from list
grep ' U ' allkosym | sort -u | awk '{ print $2 }' | while read s; do
if ! egrep -q "^[0-9a-f]* . $s\$" allkosym; then
echo $s;
fi
done > allusym
# check that kernel has entrypoints for all final undefined symbols
cat allusym | while read s; do
if ! egrep -q "^__ksymtab_$s\$" ksymtab.t; then
echo $s;
fi
done
Both scripts will generate output if you have enabled subsystems that require datastructures to change. These do not necessarily have to be data structures needed by non-native modules. However, missing entrypoints are those used by the modules. If it's about datastructures, your best chance is to lookup the data type and see if there any #ifdef CONFIG_ macros that need to be changed into #ifdef SHADOW_. If it's a missing entry point, you need to add a stub in I9000XWJP6.c.
16) Do a test-run. Pack zImage and flash with Odin.
Code:
cp arch/arm/boot/zImage .
tar cf I9000XWJP6-2.6.32.9-test.tar zImage
17) If you want more, jump to step 13
18) When you are really done, rebuild a final and fresh kernel and initramfs image with debugging stuff removed. The -gstabs compiler switch slightly influences code generation.
Code:
# not cleaning will confuse the verification
make clean
make
# install the modules
tar xf initramfs.tar
cp `find drivers -name '*.ko'` initramfs.dir/lib/modules
# rebuild with a fresh new ramdisk image
rm usr/initramfs_data.cpio*
make
My uncompressed image has now shrunk from 14700623 to 11822559 bytes.
Happy Hacking...
[...and now to find a better workaround for those non-native modules.]

WoW, Nice work !! very good info for beginners like me

thx a lot for this tut and i've learnt a lot
btw, seems there r some typos or something is missing. i did it with (XXJPO):
Hexabit said:
make I9000XWJP6_defconfig
Click to expand...
Click to collapse
make defconfig I9000XWJP6_defconfig
- modified include/linux/a.out.h by removing the 2nd def for SEGMENT
- changed the boolean to lowercase for .config
PS i use the cpio extracted by myself coz i couldnt enable libbfd on my ubuntu x64

Good tips. Thanks.

Really insightful i hope the dev take all the tweaks into consideration and make a new optimized kernel

good job here!

I think it's the most amazing first post ever! It should be sticked or kept somewhere safe.

Awesome first post. Will have to work through this.

Great post with very interesting findings!
I'm no expert, so maybe my question is a bit silly:
Is Samsung's published code just a buggy and incomplete pre-release debug version? Then how can e.g. Voodoo get a good working kernel?
Or is the official firmware really built of this, so possibly full of strange bugs and missing optimizations?

Running Homebrew Native Executables - Status: DONE!!

[2012/06/03] IMPORTANT UPDATE HERE
Hi hackers,
This is meant as a little update on one of the projects I've been working on. I'm kinda stuck now. I have a suspicion of what the problem is. I thought that maybe if I write a post about it, me or someone else will have an idea on how to get this working.
The goal is to run native homebrew executables on WP7
This has not been done yet. All apps are Silverlight apps that are compiled as DLL and run by Taskhost.exe with least privileges. All other executables are signed by Microsoft. Executables that are compiled as ARM executable cannot be started.
The angle is to create a certificate that allows to sign a WP7 executable. Then add that to the appropriate certificate store. Create an executable. Sign it with the private key. Load it onto a WP7 device. Copy it to the Windows folder. Use an OEM driver to launch the executable.
First I did research on the certificate stores. I can now with certainty state that there are 4 certificate stores:
- CA
- Root
- My
- Code Integrity
After a lot of research I finally got complete read/write access to all of these stores. The Code Integrity store contains all the certificates that are used by the Loader Verifier to verify the executable that is being launched. When the device is launched for the first time, the certificates that are in \Windows\ciroots.p7b are installed to that certificate store. These certificates have these properties:
Key Usage = 0x86 = Digital Signature, Certificate Signing, Off-line CRL Signing, CRL Signing
Entended Key Usage = Code Signing (1.3.6.1.5.5.7.3.3) + Unknown key usage (1.3.6.1.4.1.311.10.3.14)
So I used OpenSSL to create such an certificate (with private key) for myself. And I installed the certificate in the Code Integrity store.
I then used VS2008 to create a completely barebone executable (ARMv4 Console app with only Sleep(-1) in the Main). I signed it with SignTool from Microsoft.
I loaded the executable to my device and I copied it to the \Windows folder (I think the policies restrict executing to only from that folder, but I'm not sure about that).
I use the Samsung driver to launch the executable, because I need at least Standard Rights to launch an executable. The Samsung driver has Elevated Rights. My own app has only Least Privileges. Using the Samsung driver does not return any success or fail codes. But looking at the Running Processes list, I don't see my Test.exe running. It should be, because the main thread is put to sleep infinitely.
So why is this not working?
Well, I have a guess. I think it's the policies that bind the certificates in the Code Integrity store to the different accounts/chambers. In the \Windows folder there are a lot of policy xml-files. On fist boot, these are merged into PolicyCommit.xml and then compiled to policydb.vol. When the Loader Verifier (lvmod.dll) loads an executable, it queries the policies to determine access rights and chamber for that executable. The policies that matter in this context are defined in 8314B832-8D03-444f-9A2A-1EF6FADCC3B8.policy.xml. It's an xml-file that basically says this:
Code:
Microsoft Mobile Device Privileged PCA - ced778d7bb4cb41d26c40328cc9c0397926b4eea - not used in this context
Microsoft Mobile Device TCB PCA - 88bcaec267ef8b366c6e6215ac4028e7a1be2deb - honored by System Identity Group
Microsoft Mobile Device Unprivileged PCA - 1c8229f5c8d6e256bdcb427cc5521ec2f8ff011a - honored by Standard Right Identity Group
Microsoft Mobile Device VSD PCA - 91b318116f8897d2860733fdf757b93345373574 - not used in this context
VeriSign Mobile Root Authority for Microsoft - 069dbcca9590d1b5ed7c73de65795348e58d4ae3 - honored by LPC Identity Group
I should find a way to add a policy with my certificate in it. Any ideas?
Ciao,
Heathcliff74

If you are able to re-sign an executable that is already in the ROM, i would try that, so you know the problem isn't within the native code, but only with the signing. Or maybe the other way round which would be awesome.
regards

Flow WP7 said:
If you are able to re-sign an executable that is already in the ROM, i would try that, so you know the problem isn't within the native code, but only with the signing. Or maybe the other way round which would be awesome.
regards
Click to expand...
Click to collapse
That's a good idea. I must say that I don't have much faith in the current RecMod tools for WP7 right now. I am able to get the binaries recmodded so that I can disassemble them correctly. But I don't think they can be easily launched. But there are executables that are on the rom as complete binaries, instead of rom-modules. To begin with, I have to select one that does not need much privileges to run and try to sign that one and then run it.
I'm really busy with work right now, so I think I won't be able to try it until the day after tomorrow. But I will try it and will let know how that went.
Thanks!

Decompiled taskhost.exe, so it gets more easy for us to see if its able to make taskhost to start another exe for us. Lots of code tho (C code).
taskhost.c (276 KB) in attachments.
edit: Oh, WOW, this really shows how to call those anonymous methods without call signature "Hello" (signature: "??z_Hello_?mze")
Hmm, pretty much about the pause part?
Code:
if ( v10 )
{
a7 = sub_178E7(v10);
if ( a7 >= 0 )
{
a7 = sub_180A5(v7, v7 + 64);
if ( a7 >= 0 )
{
a7 = ThemeInitialize(v7 + 136);
if ( a7 >= 0 )
{
v11 = sub_1862B(v13, v7);
EnableHostAutoDehydration(v11 == 3);
v16 = 0;
a7 = InitializeEmClientEx(&a2, 0, &v16);
if ( a7 >= 0 )
{
a7 = RegisterPausedHostCallback(sub_19D0D, 0);
if ( a7 >= 0 )
{
a7 = RegisterResumingHostCallback(sub_19D31, 0);
if ( a7 >= 0 )
{
if ( v11 != 3
|| (a7 = RegisterDehydrateHostCallback(sub_19D76, 0), a7 >= 0)
&& (a7 = RegisterFreezeHostCallback(sub_19D97, 0), a7 >= 0) )
{
a7 = RegisterExitHostCallback(sub_19D55, 0);
if ( a7 >= 0 )
a7 = sub_17C0A(*(_DWORD *)(v7 + 128), 0);
}
}
}
}
}
}
}
}
UIX framework entry-point (exe)
Code:
int __cdecl sub_11114(int a1, int a2, int a3)
{
int v4; // [sp+0h] [bp-38h]@1
char Dst; // [sp+4h] [bp-34h]@1
int v6; // [sp+8h] [bp-30h]@1
int v7; // [sp+Ch] [bp-2Ch]@1
int v8; // [sp+18h] [bp-20h]@1
int v9; // [sp+28h] [bp-10h]@1
v4 = 0;
memset(&Dst, 0, 0x34u);
v8 = a3;
v6 = (int)L"res://FlightModeUXDLL!FlightMode.uix";
v7 = (int)L"FMMain";
v9 = 2;
RunApplication(&v4);
return dword_12034;
}
C++ converted
Code:
UIXApplicationInfo app;
app { ... }
RunApplication(&app);
struct UIXApplicationInfo
{
int UNK_v4 = 0;
char Dst = {0};
char* uixFile;
char* uixEntryPoint;
int UNK_v8;
int UNK_v9 = 2;
}
Then just figure out the UIX part (or test the existing "res://FlightModeUXDLL!FlightMode.uix" if it launches, if so, we made it).
___
Found this in mango dump:
> Uninstall provxml
Code:
<!-- Uninstall Xbox LIVE Extras App -->
<characteristic type="AppInstall">
<nocharacteristic type="{0c17d153-b5d5-df11-a844-00237de2db9e}"/>
</characteristic>

Is there a reason you can't just use COM interop to run native code? Check out this thread for a discussion covering the technique: http://forum.xda-developers.com/showthread.php?t=820455

athompson said:
Is there a reason you can't just use COM interop to run native code? Check out this thread for a discussion covering the technique: http://forum.xda-developers.com/showthread.php?t=820455
Click to expand...
Click to collapse
Hello "co-founder of native code on WP7"
I'm fully aware of the possibility of native code through COM. I use it for example in the WP7 Root Tools. But I just wanted to take it a step further. Running native executables give a lot more freedom. Not being bound to the watchdog, getting higher privileges and running in the background for instance. But there's a whole lot more. So that's why I started research on it. Thanks anyway. You helped making native code possible on WP7.
Ciao,
Heathcliff74

The taskhost.exe is our RAM, because our app run in it, giving us full RAM access inside our "viritual ram". So that means we own all strings, int, floats etc. Then rewrite the ram to change strings in mscorlib. The checksum if an exe has been modified is only checked at startup, without checking if we modify the dll at runtime.
My purpose with this is that some function's call external apps, where we rewrite the args going in to the function. Just find an exploitable function and modify it after JIT has been there one before generating the pre ram, that we modify and call yet again but with the modified ram values behind.
Marshal.Copy, my friends, there.
[SecurityFuckingSafeCritical]
(byte[] source, IntPtr destination, int length)
> Interopservices leaked dll (\windows)
destination = our ram ptr to modify.

fiinix said:
The taskhost.exe is our RAM, because our app run in it, giving us full RAM access inside our "viritual ram". So that means we own all strings, int, floats etc. Then rewrite the ram to change strings in mscorlib. The checksum if an exe has been modified is only checked at startup, without checking if we modify the dll at runtime.
My purpose with this is that some function's call external apps, where we rewrite the args going in to the function. Just find an exploitable function and modify it after JIT has been there one before generating the pre ram, that we modify and call yet again but with the modified ram values behind.
Marshal.Copy, my friends, there.
[SecurityFuckingSafeCritical]
(byte[] source, IntPtr destination, int length)
> Interopservices leaked dll (\windows)
destination = our ram ptr to modify.
Click to expand...
Click to collapse
Hmmm. 10 Points for inventiveness But I don't think it's going to work. Even if you could find a function where the executable is passed as argument you still don't have enough privileges. Most code will have the path to the executable hardcoded instead of an argument. And you will still run under TaskHost with Least Privileges. And you need to have at least Standard Privileges or higher to launch most executables with CreateProcess() or ShellExecuteEx().
Sent from my OMNIA7 using XDA Windows Phone 7 App

Heathcliff74 said:
Hmmm. 10 Points for inventiveness But I don't think it's going to work. Even if you could find a function where the executable is passed as argument you still don't have enough privileges. Most code will have the path to the executable hardcoded instead of an argument. And you will still run under TaskHost with Least Privileges. And you need to have at least Standard Privileges or higher to launch most executables with CreateProcess() or ShellExecuteEx().
Sent from my OMNIA7 using XDA Windows Phone 7 App
Click to expand...
Click to collapse
"And you will still run under TaskHost with Least Privileges"
I know, i dont need standard rights to do it. Because i call a mscorlib function that is trusted code. I think you saw my idea wrong, let me show you.
[mscorlib, SecuritySafeCritical]
public static void example(string str)
{
string mscorlibStr = "you cant change my value ";
Debug.WriteLine(mscorlibStr + str);
}
This is where we modify "mscorlibStr" in ram and the function is still trusted code. But its doing something totally different from that it would do.

fiinix said:
"And you will still run under TaskHost with Least Privileges"
I know, i dont need standard rights to do it. Because i call a mscorlib function that is trusted code. I think you saw my idea wrong, let me show you.
[mscorlib, SecuritySafeCritical]
public static void example(string str)
{
string mscorlibStr = "you cant change my value ";
Debug.WriteLine(mscorlibStr + str);
}
This is where we modify "mscorlibStr" in ram and the function is still trusted code. But its doing something totally different from that it would do.
Click to expand...
Click to collapse
I really hate to break it for you. But the [SecuritySafeCritical] is indeed trusted code, but it will still check your privileges. All the API functions that do system modifications like that, do the security checks. Read the note under SecuritySafeCriticalAttribute here. Also read this; same problem. You are in process TaskHost.exe and it is launched in LPC (Least Privilege Chamber), so every CeImpersonateToken() to do the important stuff will fail and return an error code. I also wouldn't know how you would modify the stack-frame of a function that you call. Seems impossible to me, because at the moment you call the function, that stack-frame has not been allocated yet.
Anyway, although I don't think that is going to work in any way, I absolutely don't want to discourage you, because my experience is that when you try enough, sooner or later you will find an exploit
Ciao,
Heathcliff74

Currently installing "Windows Embeded Compact 7", because this lousy ARMv4 compiler (from WM5-6) maybe generates wrong ARM op-codes (WP7 runs ARMv7), therefore it says "Invalid program signature" (or what error it was).
Maybe ARMv7 is'nt even backwards compatibility with ARMv4.
By compiling with the ARMv7 compiler from WEM7, it will probably (hope) generate a valid exe.
Thats it..
edit:
*Research
"Armv7 is the processor instruction set used starting with the S5L8920 in the iPhone 3GS and in all subsequent devices. Processors that support Armv7 instructions are backward compatible with Armv6 instructions, but attempting to run binaries compiled for Arm7 on older, Armv6 processors will result in the error: "Bad CPU type in executable"."
Source: http://theiphonewiki.com/wiki/index.php?title=Armv7
___
"As I said in the past, the ARMv6 CTR was kept backwards compatible with
> > > earlier versions of the ARM architecture (and ARM tried to keep it like
> > > this as much as possible). With ARMv7, you have multiple levels of cache
> > > and different types (e.g. ASID-tagged VIVT I-cache). There is no way you
> > > could encode the useful information while keeping the same (and only)
> > > register, hence the the need for a new register."
Source: http://www.spinics.net/lists/arm-kernel/msg58813.html
As i see this (^), all ARMv > 6 == no backwards
ARMv6 had backwards to 4
ARMv7 >> ARMv6 compatibility, not more.
_
Problem officer even running ARMv4???
>On a non ARMv4 backwards compatibility CPU.
Profit!!
__
[ExeX.exe] (the one that i recompiled to a state: "this has to work")(ARMv4)
Decompilation:
Code:
; Attributes: bp-based frame
EXPORT start
start
var_20= -0x20
oldR4= -0x1C
oldR5= -0x18
oldR6= -0x14
oldR7= -0x10
oldR11= -0xC
oldSP= -8
oldLR= -4
MOV R12, SP
STMFD SP!, {R4-R7,R11,R12,LR}
ADD R11, SP, #0x1C
SUB SP, SP, #4
MOV R4, R3
MOV R5, R2
MOV R6, R1
MOV R7, R0
.
Next up, decompile a ARMv7 from a raw device. (how, someone has one)

fiinix said:
Next up, decompile a ARMv7 from a raw device. (how, someone has one)
Click to expand...
Click to collapse
I think you'll find what you're looking for here: http://forum.xda-developers.com/showthread.php?t=681659 in the dump of the IMAGEFS. What did you use to decompile it? IDA Pro, or a different thing?

athompson said:
I think you'll find what you're looking for here: http://forum.xda-developers.com/showthread.php?t=681659 in the dump of the IMAGEFS. What did you use to decompile it? IDA Pro, or a different thing?
Click to expand...
Click to collapse
IDA Pro, yes. Ill see if i can dump that "nbh" (used to nb0), and extract a fully operable exe that is not corrupted.

fiinix said:
IDA Pro, yes. Ill see if i can dump that "nbh" (used to nb0), and extract a fully operable exe that is not corrupted.
Click to expand...
Click to collapse
First use Andim's WP7 Rom Tools to extract the rommodules. Remember to always dump a folder, not a single file.
Then use Denomitor's version of Recmod and follow the instructions in the post. That works most of the time.

Going forward
Currently building the WP7 ARMv7 commandline, getting closer.
Current cmd (not working, no need to help):
Code:
"C:\WINCE700\sdk\bin\i386\arm\cl.exe" /Od /D "_DEBUG" /D "_WIN32_WCE=0x700" /D "UNDER_CE" /D "ZUNE_HD" /D "WINCE" /D "DEBUG" /D "_WINDOWS" /D "ARM" /D "_ARM_" /D "_UNICODE" /D "UNICODE" /D "_CRT_SECURE_NO_WARNINGS" /Gm /EHsc /MTd /Gy /fp:fast /GR- /Fo"C:\Users\Steven VM\Desktop\ARMv7\Build\Debug/" /Fd"C:\Users\Steven VM\Desktop\ARMv7\Build\Debug/vc80.pdb" /W3 /c /Zi /TP /QRfpe- /QRarch7 "C:\Users\Steven VM\Desktop\ARMv7\main.cpp"
/QRarch7 is the ARMv7.
edit:
HOORRY SHEEAT
generated:
> main.obj
> vc80.idb
> vc80.pdb
, feels soo good:
main.exe is there.
IDA Pro says "ARM AND THUMB MODE SWITCH INSTRUCTIONS", just like others.
Code:
; Input MD5 : B50E8D8395DE7CA2419464DC3CE0BC74
; File Name : C:\Users\Steven\Desktop\burn\main.exe
; Format : Portable executable for ARMI (PE)
; Imagebase : 10000
; Section 1. (virtual address 00001000)
; Virtual size : 00000018 ( 24.)
; Section size in file : 00000200 ( 512.)
; Offset to raw data for section: 00000400
; Flags 60000020: Text Executable Readable
; Alignment : default
; Processor : ARM
; Target assembler: Generic assembler for ARM
; Byte sex : Little endian
; Segment type: Pure code
AREA .text, CODE, READWRITE, ALIGN=4
; ORG 0x11000
CODE32
EXPORT start
start
var_4= -4
SUB SP, SP, #4
MOV R3, #1
STR R3, [SP,#4+var_4]
LDR R0, [SP,#4+var_4]
ADD SP, SP, #4
BX LR
; End of function start
Made an empty entry point as from above ^:
Code:
int wWinMainCRTStartup()
{
return 1;
}
PE Explorer (main.exe):
Machine: THUMB
Operating System Version: 7.0
Image Version: 7.0
Subsystem Version: 7.0
Subsystem: WinCE GUI

**** so CLOSE!
Successful copied "main.exe" and "ExeX.exe" to "\Windows", where i have the right to launch them remotely.
Method:
WP7Process p = device.LaunchEXE(@"main.exe", "");
main.exe (no signing, ARMv7):
System.UnauthorizedAccessException: Access is denied.
WP7Process p = device.LaunchEXE(@"ExeX.exe", "");
ExeX.exe (signed with CA/ROOT custom, ARMv4):
System.Runtime.InteropServices.COMException (0x800704EC): This program is blocked by group policy. For more information, contact your system administrator.
There IS different things going on! Something is missing, but what
edit:
Signed main.exe with custom XDA ROOT certificate (ARMv7):
signtool.exe sign /sha1 "[CertChomp]" "main.exe"
> Now main.exe also gets "This program is blocked by group policy. For more information, contact your system administrator."
Ill see if i can add it to startup list , if it boot from there.
edit 2:
Nope gonna hijack "fieldtestapp.exe" with my app because policy says:
Risky-mode.Activate();
Backup(fieldtestapp.exe, backupPath);
Copy(main.exe, > fieldtestapp.exe);
"LOADERVERIFIER_ROUTE_BY_NAME"
"LOADERVERIFIER_EXE_AUTHZ_INROM_ROOT"
<Rule Description="Route fieldtestapp.exe" ResourceIri="$(LOADERVERIFIER_ROUTE_BY_NAME)/PRIMARY/WINDOWS/FIELDTESTAPP.EXE" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_LOW">
<Authorize>
<Match AccountId="$(FIELDTESTAPP_EXE_SID)" AuthorizationIds="LV_ACCESS_EXECUTE" />
</Authorize>
</Rule>
<Rule Description="Authorize fieldtestapp.exe be loadable to $(FIELDTESTAPP_EXE_SID) and chambers" ResourceIri="$(LOADERVERIFIER_EXE_AUTHZ_INROM_ROOT)/WINDOWS/FIELDTESTAPP.EXE" SpeakerAccountId="$(SYSTEM_USER_NAME)" PriorityCategoryId="PRIORITY_STANDARD">
<Authorize>
<Match AccountId="$(FIELDTESTAPP_EXE_SID)" AuthorizationIds="LV_ACCESS_EXECUTE,LV_ACCESS_LOAD" />
</Authorize>
</Rule>
edit 3:
Seems like "fieldtestapp.exe" is ROM locked. Need to try out some other targets.
edit 4:
Target acquired "ProximitySensorDisable.exe" > "ProximitySensorDisableBackup.exe"
Successful copy == no ROM lock.
edit 5:
There exists two types of talking to the LoadVerifier (the: This program is blocked by group policy.):
Direct exe name OR special certificate
How we do:
> Direct exe (hijack exe)
How we cant do (SHA1) (Nope, ain't gonna happen):
> We certainly dont have Microsofts certificate so this way is a nodo, haha lol, no do way.
(1: direct exe name) /LOADERVERIFIER/GLOBAL/AUTHORIZATION/PE_AUTHZ/NONE/NONE/PRIMARY/WINDOWS/CFGHOST.EXE
(2: static/pre certificates) /LOADERVERIFIER/GLOBAL/CERTIFICATES/HASH/SHA1/91B318116F8897D2860733FDF757B93345373574
edit 6:
Yep, loads of edits, just for you.
Allowed exe's to run (sorted a-z) (direct exe) (pre cert removed):
Code:
ACCESSIBILITYCPL.EXE
ACCOUNTSMANAGER.EXE
ALARMS.EXE
APPCHECKERSHIM.EXE
APPPREINSTALLER.EXE
AUTODATACONFIG.EXE
AUTOSIM.EXE
AUTOTIMEUPDATE.EXE
BRIGHTNESSCPL.EXE
BTUXCPL.EXE
CALENDARAPP.EXE
CALLSETTINGSHOST.EXE
CALNOT.EXE
CALUPD.EXE
CAM_FW_UPDATE_UI.EXE
CELLUXCPL.EXE
CERTINSTALLER.EXE
CFGHOST.EXE
CFLAUNCHER.EXE
CHDIALERHOST.EXE
CIPHASE2.EXE
CLIENTSHUTDOWN3.EXE
CLOCKNOT.EXE
CMACCEPT3.EXE
COLDINIT.EXE
COMMSVC.EXE
COMPOSITOR.EXE
CONFIGDM.EXE
CONFIGXML.EXE
CONMANCLIENT3.EXE
CONTACTS.EXE
CPROG.EXE
DATETIMECPL.EXE
DCVSSWITCH.EXE
DEPOTCOPY.EXE
DEVICEFEEDBACKCPL.EXE
DEVICEREG.EXE
DIAGPORTCHANGETEST.EXE
DLLHOST.EXE
DMSCHEDULERCALLBACK.EXE
DMSRV.EXE
DMSTOOLS.EXE
DUACLIENT.EXE
DW.EXE
EDM3.EXE
EMAIL.EXE
EMAILSETUP.EXE
ENDPOINT.EXE
FCROUTERCMDTEST.EXE
FIELDTESTAPP.EXE
FLIGHTMODE.EXE
GAMESUX.EXE
IEXPLORE.EXE
INITIATEDMSESSION.EXE
INVALIDLICENSEUXLAUNCHER.EXE
KEYBOARDCPL.EXE
LASSCREDENTIALEXPIRATIONCHECK.EXE
LASSRESTARTER.EXE
LIVETOKEN.EXE
LOCKCPL.EXE
LOOPBACKTEST.EXE
MEDIAGROVEL.EXE
MEUX.EXE
MITSMAN.EXE
MMSPRPROXY.EXE
MMSTRANSHOST.EXE
MULTIMEDIALAUNCHER.EXE
MYPHONECPL.EXE
MYPHONETASKSRUNTIME.EXE
NATIVEINSTALLERHOST.EXE
OFFICEURL.EXE
OMADMCLIENT.EXE
OMADMPRC.EXE
OMHUB.EXE
ONBOOTSQM.EXE
ONENOTEMOBILE.EXE
OOBE.EXE
PACMANINSTALLER.EXE
PHOTOENT.EXE
PHOTOENTCAPTURE.EXE
PHOTOUPLOADER.EXE
PPT.EXE
PWORD.EXE
PWRLOGCTRL.EXE
PXL.EXE
RAPICONFIG.EXE
REGIONCPL.EXE
RMACTIVATE.EXE
SAPISVR.EXE
SECSIMTKIT.EXE
SERVICESD.EXE
SERVICESSTART.EXE
SETTELEPORTMODE.EXE
SETTINGS3.EXE
SHORTMSG.EXE
SICLNT.EXE
SIGNALEVENT.EXE
SIREPSERVERAPPDEV.EXE
SMSETTINGS.EXE
SMSTRANSPORT.EXE
SOUNDCPL.EXE
SPEECHCPL.EXE
SPMC.EXE
SQMEVENT.EXE
SSUPDATE.EXE
TASKHOST.EXE
TELSHELL.EXE
TESTSHOW.EXE
THEMECPL.EXE
TOGGLEBROWSERHIBERNATION.EXE
TOGGLEDOG.EXE
UDEVICE.EXE
UIF.EXE
UNIFIEDPAIR.EXE
USBMGR.EXE
WEBSEARCH.EXE
WIFIUXSPLASH.EXE
WLANEXT.EXE
WLIDSETUP.EXE
WWANDATAMGR.EXE
XDRMREMOTESERV.EXE
ZIPVIEW.EXE
ZMFTASKLAUNCH.EXE
How code (yes i know its super un-optimized, fast put together):
Code:
var doc = XDocument.Load(File.OpenRead("SamsungOmnia7_BasePolicy_webserver.xml"));
var ea = doc.Elements().ToArray()[0].Elements()
.Where(x => x.Name.LocalName == "Rule")
.Where(x => x.Attributes("ResourceIri").Count() > 0)
.Where(x =>
{
var r = x.Attribute("ResourceIri").Value;
return r.Contains("LOADERVERIFIER") && r.ToLower().Contains(".exe") && !r.Contains("CERTIFICATES");
})
.Select(x =>
{
var v = x.Attribute("ResourceIri").Value;
var l = v.LastIndexOf('/');
return v.Substring(l + 1);
})
.Distinct()
.OrderBy(x => x)
.ToArray();
edit 7:
yeah, lol i say too.
Unprotected exe (FCRouterCmdTest.exe)
> c:\Project Work\SGH-i707(Cetus)\FCRouterCmdTest\Windows Mobile 6 Professional SDK (ARMV4I)\Release\FCRouterCmdTest.pdb
mfw samsung use "Windows Mobile 6 Professional SDK (ARMV4I)"

Wow, this truly was a big step today
Done hacking today.
"After a day, there comes another day"

@fiinix,
You did a lot of testing. Good job, man.
A few comments:
0x800704ec "blocked by group policy" is THE error of the new WP7 security model. It is basically telling you to go f*ck yourself. Everything you do without enough privileges or capabilities results in this error.
The two ways of policies, exe-path and cert-hash, is result of difference between rom-modules and executables that are signed and added as a file. Rom-modules are not even normal files. You can't open and read them. They are executable sections that are mapped in rom-address-space. You can only call loadlibrary() and createprocess() on them. Since they are only executable sections, they don't have a signature, like a normal executable file would have. Therefore they are referred to with an exe-path. You may safely assume that every path to an executable in the policy files is referring to a rom-module and can't be overwritten in any way (except by cooking your own rom - who is going to unlock our bootloaders?!?) Other than that, there are a few signing certs that Microsoft has. Signing the different executables with different privileges and accordingly a different cert. Their hashes are in the policies.
Using ARMv7 isn't going to add much I'm afraid. Although it may make a difference in the exe-header. But you've seen tools that were really old, remember And they were signed to have TCB access. And they were compiled for ARMv4. So it should not make much difference.
I did some testing with certificates myself yesterday. Up until Zune totally went bezerk on it. I don't know what happened, but after removing my own cooked certs it all seems normal again. Zune started using 100% cpu on verifying certs and dropping my connection all the time. Help! So I haven't made much progress. I will try again later. Hope it will go better. And I will try to resign an existing executable, as Flow WP7 suggested.

According to policy on my omnia (webserver dumped) there seems to exist two typed of HDD, one ROM hard coded and one that points to internal sd card. It seems that all exe and dll on the sd are not "protected" and therefore can be hijacked.
Seems like ARMv4 will be enough, but to be on the safe side i compile with both, to have more chance getting it work.
Zune, hmm, did not seem to like you, maybe Microsoft DDOS'ed you lol
"Sent from my fingers on my phone", don't expect way too long text

XxXPachaXxX said:
Excuse my ignorance...I'm a noob...This hack may also work on LG devices?
Click to expand...
Click to collapse
At the moment fiinix and I are both working on Samsungs and we use a couple of Samsung-specific exploit to get deeper in the system and getting a better understanding of the system. The ultimate goal is to find exploits that will work for all devices. But we're not at that stage yet. Hacking is research, a lot of trying and being lucky sometimes. Just bear with us
Ciao,
Heathcliff74

[dev][kernel][kexec]

Last Update : August, 19, 2014
Hi,
I'm still try to bypass the MMU protection.
I have fixe a lot of bug, like memory misalignment, bad adresses allocation, dtb correction, etc...
Last sources and binaries here :
kexec-tools V11.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2902912&stc=1&d=1408401794
kexec-tools binaries V11.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2902913&stc=1&d=1408401794
Sorry, i have always 13 sec reboot after new kernel boot.
"cpu_proc_fin" use a "mcr p15" to init cache and proc that cause freeze.
I try to find solution for that.
Last Update : June, 22, 2014
Hi,
My sources are horrible... but i give something new.
This kexec is for stock kernel only (tested on .757). I thinks theses sources work on other kernel too.
In "kexec-tools V10.zip", you have all my sources. It's highly recommended to mod them to have something OK.
In "kexec binaries.zip", you have binaries to install
=> "kexec_load.ko" and "procfs_rw.ko" must be placed in "/system/lib/modules" folder with "chmod 777"
=> "kexec" must be placed in /system/bin" folder with "chmod 777"
=> cd /system/lib/modules
=> insmod kexec_load.ko
For sources :
Mod and adapt all you want, it's free.
You have 2 scripts in Zip : "./compil-kexec" in "kexec-tools" folder to rebuild and send in device directly (install Adbtcp on device and send by tcp with : adb connect xxx.xxx.xxx.xxx) = work perfectly with me.
"scriptZ1" is for compil stock kernel or another kernel (doomlord kernel for eg)
You must rename "custom_final_files" folder after compil to "final_file" manually ; You can have guest kernel in "custom_final_files" and stock kernel in "final_files" for "kexec-tools" path ... Don't mix a guest and host kernel please ^^
I am tired... i let you test and say if it's ok for you...
Thank a lot to munjeni for his help.
kexec-tools V10.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2811994&stc=1&d=1403456181
kexec binaries.zip : http://forum.xda-developers.com/attachment.php?attachmentid=2811995&stc=1&d=1403456181
Last Update : November, 23, 2013
Hi,
For few days now, i haven't no more kernel panic with my kexec.
I have fixed few stuffs into sources, and add a lot.
These adds are, to include a "dt.img" image file into kexec load process.
This image file is a "device_tree" image to match hardware to software.
So, i assume to don't include atags into boot process, but pass bootloader informations by this DT.
I have programmed a little scan memory to found dynamicly all magic tags, because i found 3 device_tree into memory (magic is "0xd00dfeed").
These 2 device_tree are echo from first and nice structure.
The boot process need to have informations from this DT, and need all informations to initialize hardware (no HDW initialisation by the kernel)
I must first fix issues ; Regroup zImage and dt.img into memory to load a solid bloc to kexec_load module to boot into, and second, fix an offset i can't explain, 0x800 in memory causing misalignment memory
Keep tuned..
Last Update : November, 17, 2013
Hi everybody,
My kexec-tools work for Sony Xperia Z1 stock kernel "3.4.0-perf"
This tools can work on all locked bootloader for all locked device, not only Sony or Z1 models.
This kexec-tools add a kexec_load kernel module (LKM) and use a driver to grant a communication between "kexec" user program and kexec_load.ko module
what is for ?
"kexec" user program load in memory a custom kernel in zImage format, but can load ".tar" image too
This user tool load ramdisk in memory if necessary
This tool is for this purpose only, and don't keep in memory the custom kernel at device reboot.
It is a "user" program, not a "kernel" extension... So, to really do the magic, we need the host kernel (stock sony locked kernel) have a kexec_load capability to reboot in a new gest kernel (custom kernel).
Infortuntly, stock kernel don't have kexec_load capability.
Sony have compiled his stock kernel without this option, and "standard" kexec-tools "need" this option to work.
To see all system call capability of kernel, you can run theses command :
Code:
echo 0 > /proc/sys/kernel/dmesg_restrict
echo 0 > /proc/sys/kernel/kptr_restrict
cat /proc/kallsyms
Do all grep you want here.
The "echo 0" "restrict" is here to unmask logical adresses to "system calls"
Like you can see, "__NR_kexec_load" capability isn't here.
To add kexec_load capability in stock locked kernel, we need to add manualy a kernel module wich add this function into the kernel.
Why ? Because the way to keep in memory a custom kernel need to know a lot of parameters, and keep a specific memory range alive at reboot.
Only kernel can do this.
All user program will be terminated at reboot.
"Standard" kexec_load.ko module use a method to implement the "__NR_kexec_load" function in system call table.
Since 2.6.0 kernel, linux for security reason, have locked in memory the "system_call_table" ; No more add or modification is authorized.
If kexec tool try to add a value, "kexec_load" for us, we causes a kernel panic, and reboot device.
For this reason, i have modify kexec user program and kexec_load module to implement a driver to talk to each other.
this driver replace syscall method, and we no more need to use a system call table.
For this reason, this tool is now compatible with modern kernel like our "3.4.0"
For this reason, this tool must work for other device (Xperia X, P, S, etc...) and another brand
For this reason, if kernel is locked, we can bootstrap to run a new kernel.
Installation
First, you can compil your own kexec tool
Here, sources : http://forum.xda-developers.com/attachment.php?attachmentid=2397299&stc=1&d=1384689174
And here, the binaries : http://forum.xda-developers.com/attachment.php?attachmentid=2397305&stc=1&d=1384689406
(it's not a cwm zip, i have no time to create an installer for now ; use "./compil-kexec" if you want an automatic install)
Install *.ko in /system/lib/modules
Install kexec and kdump in /system/bin
Grant with "chmod 777"
Unzip in kexec-tools folder
Install a toolchain (sudo apt-get install gcc-arm-linux-gnueabi)
launch => ./compil-kexec
what's all
This script can do everythinks for you
- Compilation of tools
- Compilation of modules
- installation in device
This script can compil for every brand you have.
Except you must remove or adapt the patch (see below why)
Patch ??
This patch is because a module must be compiled in the same time the kernel himself.
For this reason a "vermagic", an identifier, is used by system to block every module not compil with kernel
Some custom kernel bypass this to authorize every modules.
But for stock kernel, it is not allowed.
You can easely strapp this by busybox.
"busybox modprobe" for help
"-f" to force load without vermagic
To see this vermagic :
Code:
# uname -r
This "uname -r" must be the same that
Code:
# strings kexec_load.ko | grep vermagic
vermagic=3.4.0-perf-g66807d4-02450-g9a218f1 SMP preempt mod_unload modversions ARMv7
If you want use automaticaly this vermagic, you can modify into the custom kernel this file :
Code:
"include/config/kernel.release" and add :
"3.4.0-perf-g66807d4-02450-g9a218f1"
This file will be use at module compil to match the vermagic.
Infortunatly, it is not enought. :silly:
The infamous "no symbol version for module_layout"
When a module compil is created, it use symbols link to system call function, translate by adresses
Theses symbols are not at same physical adresses in stock kernel and modules (compiled from DooMLoRD kernel).
So, theses adresses must be convert into modules itself to match with stock symbols adress.
A patch is needed.
If you use my script, modules are automatically patched.
Here patches :
Code:
sed -i 's/\x32\x76\x86\x29/\x72\xFF\x5E\x20/' procfs_rw.ko
sed -i 's/\x32\x76\x86\x29/\x72\xFF\x5E\x20/' kexec_load.ko
sed -i 's/\xBB\xD0\xF8\x4D/\x0E\x1C\x63\x77/' kexec_load.ko
sed -i 's/\xA6\x26\x81\x1A/\xD4\x56\x02\x7E/' kexec_load.ko
sed -i 's/\xA3\xD1\xEC\x96/\xEC\x43\x28\x1A/' kexec_load.ko
sed -i 's/\x8C\xE6\x6A\x5F/\x3D\xDF\x02\xF2/' kexec_load.ko
sed -i 's/\x3E\xF3\xEF\xE9/\x18\x7F\xA6\x8A/' kexec_load.ko
sed -i 's/\x8B\xD2\x92\x10/\xC8\x19\x08\x9C/' kexec_load.ko
sed -i 's/\x1C\xE8\x18\xE1/\x7C\x71\x9E\xEF/' kexec_load.ko
sed -i 's/\xAB\x2C\x2F\x8B/\x8E\xD7\x63\xC0/' kexec_load.ko
sed -i 's/\xF5\x62\xAA\x4B/\x34\x80\x1B\x74/' kexec_load.ko
sed -i 's/\x00\x52\xD6\xD7/\x6F\x80\x91\x20/' kexec_load.ko
sed -i 's/\x4F\x77\x57\x6A/\x0C\x57\xC7\x63/' kexec_load.ko
sed -i 's/\xCA\x2F\x65\x71/\x92\xB8\x7F\x53/' kexec_load.ko
sed -i 's/\x0F\xD0\xA0\x91/\xFA\x80\x15\xB4/' kexec_load.ko
sed -i 's/\x29\xA0\x6D\x48/\x6C\x6B\x96\x54/' kexec_load.ko
sed -i 's/\x6D\x1F\x1F\x37/\xCC\x5E\x79\x8B/' kexec_load.ko
sed -i 's/\xFD\x23\xD0\xFB/\xE3\xE3\x68\x52/' kexec_load.ko
You can use hexedit or hexdump to see these adresses :
Code:
hexdump kexec_load.ko | grep ff72
0003d50 b0b0 80ac ff72 205e 6f6d 7564 656c 6c5f
how does it work ?
# kexec --help
For kexec help... nothing more to say.
# lsmod
List loaded modules... You must see
kexec_load 31369 0 - Live 0x00000000 (O)
# rmmod kexec_load.ko
Remove kexec_load module from memory.
# grep kexec /proc/device
To see installed driver.
You must see :
100 kexec_driver
First number is "major" number to identify your driver in system.
# mknod /dev/kexec_driver c 100 0
Install driver.
Major number (here 100), is important for module.
This Major must be the same between module and driver.
By default, 100 is used.
# insmod kexec_load.ko
To install "LKM", kexec_load kernel module.
If another Major is needed, you can use "insmod kexec_load.ko 101" for Major 101
You can use "modprob" if you want, but you must configure the module folder.
How kexec and module exchange informations ?
By the driver.
Normal output for a kernel module is to write in "dmsg" file.
To see kernel output, launch this command :
Code:
# dmesg
To see last kernel log, see in :
Code:
# cat /proc/last_kmsg
For kexec module, this normal way still exist, and give a lot of informations, but to speak with, you must use the driver.
/dev/kexec_driver
You can yourself test communication:
Code:
# cat /dev/kexec_driver
You can send kernel by this communication channel.
Type following commands for help
=> echo help >/dev/kexec_driver
=> dmesg | grep Kexec
Code:
# echo help >/dev/kexec_driver
# cat /dev/kexec_driver
Last command : 'help'
Please type following command :
=> dmesg|grep Kexec
Every command send into driver is receive by kexec_load.ko module and running into the kernel.
The answer can by read thru the driver
Here, you can see that normal way to see messages is allway dmesg.
Code:
# dmesg|grep Kexec
<4>[15050.521628] Kexec: Starting kexec_module...
<6>[15050.521656] Kexec: kexec_driver_contener allocation
<6>[15050.521673] Kexec: kexec_memory_buffer allocation
<4>[15050.521691] Kexec:----------------------------------------------------
<4>[15050.521710] Kexec: kexec_driver created with major : '100'
<4>[15050.521728] Kexec: Please, prepare by typing the following commands :
<4>[15050.521746] Kexec: => mknod /dev/kexec_driver c 100 0
<4>[15050.521761] Kexec: => cat /dev/kexec_driver
<4>[15050.521775] Kexec:-----------------------------------------------------
<4>[15050.521791] Kexec: For help
<4>[15050.521803] Kexec: => echo help >/dev/kexec_driver
(...)
I have add a lot of informations to help to configure kexec.
rdtags, atags ??
Not sure for this part of kernel.
"atags" is the most used method to bootloader to parse commands and informations to kernel at boot.
"atags" is a form of structure in memory to organise informations.
At boot, a address chain is created and can be compulse in /proc/atags file.
This file is read only system.
"rdtags" is another way to bootloader to parse information to kernel.
"rdtags" is not stocked in "/proc"
But, as i see, stock kernel can use "atags" from bootloader.
kexec can substitute bootloader function to create fromscratch a atags chain, and parse to new kernel.
I have change this part to stock atags in "/data/atags", and reuse or change if need.
If this don't work, i must create a rdtags chain to replace atags ; It's not a hard work.
Status
For the moment, kexec tools works.
=> Phase one OK.
I can start Phase Two : new kernel patch.
If you want to help me...
Actually, load a custom kernel and boot into with kexec tools work.
But at boot into, a kernel panic occurs.
It seems, a part of kexec patch is missing in custom kernel.

Hi new thread created for kernel kexec development.
Status: not working: wrong values for mem defines under the kernel is giving segmentation fault as its attempting to write to memory areas that are currently being used byyyyy the system
Instructions:
Make kernel compatible?:
1. Download kernel diff patch from below
2. Terminal - diff patch > diff.txt
How to use:
1. Download kexec-tools (kexec binary) from below
2. Copy into system/bin directory and give it executable permission
3. Download compatible kernel
4. Terminal - kexec --load-hardboot zImage --initrd=initrd.img --mem-min=0x20000000 --command-line="$(cat /proc/cmdline)"
kexec -e
Download links:
Kexec tool- https://db.tt/8DZXQ9eV
Ramdisk firmware 1.548 : https://db.tt/8DZXQ9eV
zImage (kernel):
Source code:
Kernel diff patch: https://db.tt/Xi2htT7Q (currently contains wrong values for mem defines)
Kexec-tools: https://db.tt/I22ofr3b
Special thanks: @delewer @krabappel2548

Reserved

Please move this thread to Xda Devdb, then I can also edit first post etc if I find new stuff
Sent from my C6903 using xda app-developers app

krabappel2548 said:
Please move this thread to Xda Devdb, then I can also edit first post etc if I find new stuff
Sent from my C6903 using xda app-developers app
Click to expand...
Click to collapse
Devdb?
Pm me i dont know what Devdb is lol

Recieved segmentation fault with delewers calculated mem values too
We need to write to memory where we have write access to, maybe lockedbootloader is not allowing us to write? Orrr we are just writing to wrong area of memory

If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.

Shaky156 said:
Devdb?
Pm me i dont know what Devdb is lol
Click to expand...
Click to collapse
Shaky156 said:
Recieved segmentation fault with delewers calculated mem values too
We need to write to memory where we have write access to, maybe lockedbootloader is not allowing us to write? Orrr we are just writing to wrong area of memory
Click to expand...
Click to collapse
I'll discuss with Kali- today if he's available.
Knucklessg1 said:
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Click to expand...
Click to collapse
Doesn't need to be same processor, can be ported
Sent from my C6903 using xda app-developers app

Knucklessg1 said:
If kexec works on the Z1, can it be ported over to Xperia Z/ZL/T/Ultra? I believe they don't all share the same processor.
Click to expand...
Click to collapse
Yes it wont matter much, since its not s800 it should be easier for you guys , take the kexec-tool use that, implement the patch write to the correct mem addresses which is free, it should boot if you guys have issues let me know,
I need to calculate the correct addresses.
Ive noticed s800 uses a dt.img, might need to modify kexec-tool to support dt.img, not sure what dt.img does yet, only know it holds values

Shaky156 said:
I need to calculate the correct addresses.
Ive noticed s800 uses a dt.img, might need to modify kexec-tool to support dt.img, not sure what dt.img does yet, only know it holds values
Click to expand...
Click to collapse
the dt.img is needed by the kernel to boot, so I guess we need to load that too in kexec.
EDIT: people that wanna try add kexec patch to their kernel, check github: android_kernel_sony_msm8974/commits/kexec

krabappel2548, i have compil your kernel by my script (fromscratch)
My script (instruction in "DoomLord Build kernel thread" : scriptZ1 http://forum.xda-developers.com/attachment.php?attachmentid=2346163&d=1382568778
(for thoses who want to help us...)
You have a little mod to do here (bad compil) :
In "sound/soc/msm/qdsp6v2/rtac.c"
you must change
#include <q6voice.h>
by
#include "q6voice.h"
btw : no more ideas to load kexec for the moment ...

delewer said:
krabappel2548, i have compil your kernel by my script (fromscratch)
My script (instruction in "DoomLord Build kernel thread" : scriptZ1 http://forum.xda-developers.com/attachment.php?attachmentid=2346163&d=1382568778
(for thoses who want to help us...)
You have a little mod to do here (bad compil) :
In "sound/soc/msm/qdsp6v2/rtac.c"
you must change
#include <q6voice.h>
by
#include "q6voice.h"
btw : no more ideas to load kexec for the moment ...
Click to expand...
Click to collapse
Sorry, I'm trying to get caught up on the forum, but what seems to be the current standing issue to get kexec working?

Knucklessg1 said:
Sorry, I'm trying to get caught up on the forum, but what seems to be the current standing issue to get kexec working?
Click to expand...
Click to collapse
Read the OP
Status paragraph

Memory regions
00000000-07afffff : System RAM
00008000-00b79383 : Kernel code
00d04000-00f0cddb : Kernel data
0ff00000-779fffff : System RAM
7ff00000-7ff3ffff : rdtags_mem
7ff80000-7ffa0fff : last_kmsg
7ffa1000-7ffa5fff : last_amsslog
System RAM MEM = 00000000
So --min-mem=0x20000000
Now need to find a free memory area thatll allow us to write and hopefully the mmu/pmu on locked bootloader wont cancel it
@delewer? @DooMLoRD @kali @Bin4ry

I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app

king960 said:
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
Click to expand...
Click to collapse
These devices are not 2013 devices, they arent s800 socs, so they are much easier to do, simply take the kexec-tools from op, implement the patch in your kernel, write the correct memory values for your specific device and execute in terminal via the command in op, minmem depends on your device too, good luck

I think some1 tried it already, but it works only for unlocked devices... Anyway, thanks for help.
Sent from my LT22i using xda app-developers app

king960 said:
I know I shouldn't disturb, but i must ask: if You achieve Your goal, would it be possible to port it to devices like Xperia P, S, T, U and other NXT? It would be great, many ppl are ready to give a prize for it. Thanks in advance, good luck and sorry again.
Sent from my LT22i using xda app-developers app
Click to expand...
Click to collapse
Does doing this require having an Unlocked Boot loader prior to implementation?
Sent from my C6603 using xda app-developers app

A few informations about kexec-tools debug
in kexec.c
Fonction :
if (file_type.load(argc, argv, kernel_buf,
kernel_size, &info) < 0) {
fprintf(stderr, "Cannot load %s\n", kernel);
return -1;
}
With a forced execution of kexec (bypass error to see...)
--mem-min=0x90000000
kernel: 0xb6b9d008 kernel_size: 3e9340
debug: 1 - after get memory range
debug: 2 - after type test
debug: 3 - after type test
debug: 4 - after info.kexec
debug: Focus 1 - argc '5' ; argv 'be856774' ; kernel_buf 'b6b9d008' ; kernel_size '3e9340' ; info 'be856548' ; i '1' ; file_type.name 'zImage'
Could not find a free area of memory of 3f1340 bytes...
Cannot load zImage
debug: 10 - before trampoline
debug: 11 - after trampoline
debug: 12 - before segment load
debug: 13 - after segment load
debug: 8 - before sort_segment
debug: 9 - after sort_segment
debug: 6 - before purgatory
debug: 7 - after purgatory
kexec_load: entry = (nil) flags = 280004
nr_segments = 0
kexec_load failed: Function not implemented
entry = (nil) flags = 280004
nr_segments = 0
debug: 5 - return result : ffffffff
With a forced bypass on file_type.load , we have this :
--mem-min=0x20000000
debug: Focus 1 - argc '5' ; argv 'bef18774' ; kernel_buf 'b6bc7008' ; kernel_size '3e9340' ; info 'bef18548' ; i '1' ; file_type.name 'zImage'
Segmentation fault

delewer said:
A few informations about kexec-tools debug
in kexec.c
Fonction :
if (file_type.load(argc, argv, kernel_buf,
kernel_size, &info) < 0) {
fprintf(stderr, "Cannot load %s\n", kernel);
return -1;
}
With a forced execution of kexec (bypass error to see...)
--mem-min=0x90000000
kernel: 0xb6b9d008 kernel_size: 3e9340
debug: 1 - after get memory range
debug: 2 - after type test
debug: 3 - after type test
debug: 4 - after info.kexec
debug: Focus 1 - argc '5' ; argv 'be856774' ; kernel_buf 'b6b9d008' ; kernel_size '3e9340' ; info 'be856548' ; i '1' ; file_type.name 'zImage'
Could not find a free area of memory of 3f1340 bytes...
Cannot load zImage
debug: 10 - before trampoline
debug: 11 - after trampoline
debug: 12 - before segment load
debug: 13 - after segment load
debug: 8 - before sort_segment
debug: 9 - after sort_segment
debug: 6 - before purgatory
debug: 7 - after purgatory
kexec_load: entry = (nil) flags = 280004
nr_segments = 0
kexec_load failed: Function not implemented
entry = (nil) flags = 280004
nr_segments = 0
debug: 5 - return result : ffffffff
With a forced bypass on file_type.load , we have this :
--mem-min=0x20000000
debug: Focus 1 - argc '5' ; argv 'bef18774' ; kernel_buf 'b6bc7008' ; kernel_size '3e9340' ; info 'bef18548' ; i '1' ; file_type.name 'zImage'
Segmentation fault
Click to expand...
Click to collapse
Did you compile this kexec yourself? Or did you get this from krapabbel? I issued krapabbel to compile a new debug version have gave him the code but never heard back from him :/
Anywayz so cannot find free memory is the issue

Requesting help with "make-standalone-toolchain.sh" for AFTV2

Yesterday, I cross-compiled DropBear for the 2nd Gen Fire TV, but I am receiving a linkage error that points to it being compiled with an incorrect toolchain.
I downloaded and extracted the "android-ndk-r10e-linux-x86_64.bin" and used the following command to make the standalone toolchain:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=arm-linux-androideabi-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
What are the correct platform and toolchain for the AFTV2 on 5.0.4? I tried to look this up, but I was unable to find it posted in any of the expected places. If I don't hear back, I suppose I'll give it a try with aarch64-linux-android-4.9, because the error I'm receiving when I try to connect to server complains about the bitness of "libc.so" (is 32-bit instead of 64-bit), but I can't even seem to find confirmation that the AFTV2 uses a 64-bit arm processor.
Thanks,
William

fecaleagle said:
Yesterday, I cross-compiled DropBear for the 2nd Gen Fire TV, but I am receiving a linkage error that points to it being compiled with an incorrect toolchain.
I downloaded and extracted the "android-ndk-r10e-linux-x86_64.bin" and used the following command to make the standalone toolchain:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=arm-linux-androideabi-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
What are the correct platform and toolchain for the AFTV2 on 5.0.4? I tried to look this up, but I was unable to find it posted in any of the expected places. If I don't hear back, I suppose I'll give it a try with aarch64-linux-android-4.9, because the error I'm receiving when I try to connect to server complains about the bitness of "libc.so" (is 32-bit instead of 64-bit), but I can't even seem to find confirmation that the AFTV2 uses a 64-bit arm processor.
Thanks,
William
Click to expand...
Click to collapse
Yes, you need aarch64. I've used both the NDK and the aarch64 compiler straight from AOSP. Both work.

rbox said:
Yes, you need aarch64. I've used both the NDK and the aarch64 compiler straight from AOSP. Both work.
Click to expand...
Click to collapse
Thanks, I actually just rebuilt the toolchain with aarch64 and re-compiled. I'll follow-up, because I'm assuming that was the only thing preventing the server from functioning properly. Thanks for all your assistance.

fecaleagle said:
Thanks, I actually just rebuilt the toolchain with aarch64 and re-compiled. I'll follow-up, because I'm assuming that was the only thing preventing the server from functioning properly. Thanks for all your assistance.
Click to expand...
Click to collapse
Well, I'm obviously still doing something wrong. The file command on my build-system reports:
Code:
./dropbearmulti: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, stripped
, which looks correct.
But clients are still receiving the following error when I try to connect to the server:
Code:
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
I'll keep digging, but basically, I am building the toolchain like so:
Code:
/home/william/android-ndk/build/tools/make-standalone-toolchain.sh --ndk-dir=/home/william/android-ndk --platform=android-21 --toolchain=aarch64-linux-android-4.9 --system=linux-x86_64 --install-dir=/home/william/aftv2-toolchain
Then running configure:
Code:
./configure --build=x86_64-unknown-linux-gnu --host=aarch64-linux-android --prefix=/home/william/aftv2-toolchain --disable-zlib --disable-largefile --disable-loginfunc --disable-shadow --disable-utmp --disable-utmpx --disable-wtmp --disable-wtmpx --disable-pututline --disable-pututxline --disable-lastlog
Then, I am setting CC and PATH to the following:
Code:
CC=aarch64-none-linux-gnueabi-gcc
PATH=/home/william/aftv2-toolchain/bin:$PATH
Then, I am building as such:
Code:
STATIC=1 MULTI=1 SCPPROGRESS=0 PROGRAMS="dropbear dropbearkey scp dbclient" make strip
No complaints during the build or from the file command, but the issue persists. Surely I am missing something.

Interesting. So when I poke around my toolchain, all of the copies of libc.so are 64-bit, according to the linux file command.
However, just to see if it would tell me anything, I compiled the binary dynamically-linked rather than statically linked and used the ndk-depends tool, and it reports the following:
Code:
Building dependency graph...
dropbearmulti depends on: libc.so libdl.so
Android system library: libc.so
Android system library: libdl.so
Building sorted list of binaries:
dropbearmulti -> ./dropbearmulti
libdl.so -> $ /system/lib/libdl.so
libc.so -> $ /system/lib/libc.so
This obviously indicates that when I build dynamic, it is attempting to link with the 32-bit libraries and not the 64-bit libraries. How can I correct this so that when I do any build, the linkages are correct?

fecaleagle said:
Interesting. So when I poke around my toolchain, all of the copies of libc.so are 64-bit, according to the linux file command.
However, just to see if it would tell me anything, I compiled the binary dynamically-linked rather than statically linked and used the ndk-depends tool, and it reports the following:
Code:
Building dependency graph...
dropbearmulti depends on: libc.so libdl.so
Android system library: libc.so
Android system library: libdl.so
Building sorted list of binaries:
dropbearmulti -> ./dropbearmulti
libdl.so -> $ /system/lib/libdl.so
libc.so -> $ /system/lib/libc.so
This obviously indicates that when I build dynamic, it is attempting to link with the 32-bit libraries and not the 64-bit libraries. How can I correct this so that when I do any build, the linkages are correct?
Click to expand...
Click to collapse
I was compiling kexec dynamically by setting CC and it was working. And I've compiled other things with Android.mk files using the NDK and compiling them static and it worked. Why are you compiling dropbear static to begin with? You say CLIENTS are receiving that message. It almost sounds like dropbear is trying to fork a 32bit shell for them. Since you are running dropbear as the server fine, itself is compiled correctly...

rbox said:
I was compiling kexec dynamically by setting CC and it was working. And I've compiled other things with Android.mk files using the NDK and compiling them static and it worked. Why are you compiling dropbear static to begin with? You say CLIENTS are receiving that message. It almost sounds like dropbear is trying to fork a 32bit shell for them. Since you are running dropbear as the server fine, itself is compiled correctly...
Click to expand...
Click to collapse
I'm compiling static because I'm following the guide posted here:
http://forum.xda-developers.com/nexus-7-2013/general/guide-compiling-dropbear-2015-67-t3142412
Running the dynamically-linked version on the fire tv reports:
Code:
error: only position independent executables (PIE) are supported.
I suppose I should be reaching out to @jocala at this point, since I'd guess he's managed to compile it successfully for the 2nd gen fire tv.

fecaleagle said:
I'm compiling static because I'm following the guide posted here:
http://forum.xda-developers.com/nexus-7-2013/general/guide-compiling-dropbear-2015-67-t3142412
Running the dynamically-linked version on the fire tv reports:
Code:
error: only position independent executables (PIE) are supported.
Click to expand...
Click to collapse
http://stackoverflow.com/questions/...id-l-error-only-position-independent-executab
You need to enable PIE in CFLAGS and LDFLAGS:
CFLAGS = -fPIE
LDFLAGS = -fPIE -pie

fecaleagle said:
I suppose I should be reaching out to @jocala at this point, since I'd guess he's managed to compile it successfully for the 2nd gen fire tv.
Click to expand...
Click to collapse
I'm working on the adbFire update for AFTV2 root; ssh is on the list, but I'm not there yet.

rbox said:
http://stackoverflow.com/questions/...id-l-error-only-position-independent-executab
You need to enable PIE in CFLAGS and LDFLAGS:
CFLAGS = -fPIE
LDFLAGS = -fPIE -pie
Click to expand...
Click to collapse
Doing this allows it startup correctly dynamically linked, but clients still fail to connect. Debian reports the most useful information:
Code:
dispatch_protocol_error: type 51 seq 6
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
As usual, dropbear reports:
Code:
[6329] Jan 04 13:48:35 Child connection from 192.168.1.210:53425
void endusershell()(3) is not implemented on Android
void endusershell()(3) is not implemented on Android
[6329] Jan 04 13:48:42 password auth succeeded for 'root' from 192.168.1.210:53425
[6329] Jan 04 13:48:43 Exit (root): Disconnect received
To me, it appears that the server is throwing up the error to the client, but I still suspected that I am linking the 32-bit version of libc.so when I build dropbear, and I am still at a loss for how to correct that.
Thanks for all of your help. I'll get there eventually.

fecaleagle said:
Doing this allows it startup correctly dynamically linked, but clients still fail to connect. Debian reports the most useful information:
Code:
dispatch_protocol_error: type 51 seq 6
CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit
As usual, dropbear reports:
Code:
[6329] Jan 04 13:48:35 Child connection from 192.168.1.210:53425
void endusershell()(3) is not implemented on Android
void endusershell()(3) is not implemented on Android
[6329] Jan 04 13:48:42 password auth succeeded for 'root' from 192.168.1.210:53425
[6329] Jan 04 13:48:43 Exit (root): Disconnect received
To me, it appears that the server is throwing up the error to the client, but I still suspected that I am linking the 32-bit version of libc.so when I build dropbear, and I am still at a loss for how to correct that.
Thanks for all of your help. I'll get there eventually.
Click to expand...
Click to collapse
Dropbear itself is 64-bit, because you are actually running it fine. If you could turn up the logging on dropbear, maybe you can get it to tell you what it's doing between password succeeded and disconnect received. Or you could just add a ton of logging to the code. My guess is it's forked the connection and trying to start a secondary program, and that program isn't 64bit. My guess would be the shell, but it should just be using the system shell, so unsure.

jocala said:
I'm working on the adbFire update for AFTV2 root; ssh is on the list, but I'm not there yet.
Click to expand...
Click to collapse
Thanks for your work on adbFire. I'll report back if I'm ever able to get this resolved.

rbox said:
Dropbear itself is 64-bit, because you are actually running it fine. If you could turn up the logging on dropbear, maybe you can get it to tell you what it's doing between password succeeded and disconnect received. Or you could just add a ton of logging to the code. My guess is it's forked the connection and trying to start a secondary program, and that program isn't 64bit. My guess would be the shell, but it should just be using the system shell, so unsure.
Click to expand...
Click to collapse
This suggestion is making more and more sense. I'll take a look at the source and start thinking about my own patchset for the latest source version. I'm annoyed that the verbose flag is not included in the source version of dropbear that the patch was created for, so I think I will end up going that route eventually. I'll take your advice and focus adding debug messages when dropbear initializes the shell, since the authentication goes of without a hitch and it's at that point that the process breaks down. I really appreciate all of your suggestions!

@rbox,
This is rather helpful, and the post from July 31st, 2015 all but confirms your suspicion about forking the shell and points me in the right direction:
http://www.kevinboone.net/kbox3_diary.html
I will start by modifying the patches to use: /bin/sh rather than /system/bin/sh when launching the shell and see if that resolves my issue, then get started on the long slog.

The blog post above seems to have shed some light on the issue. Updating the patches to refer to /bin/sh rather than /system/bin/sh seems to have resolved the "CANNOT LINK EXECUTABLE DEPENDENCIES: "libc.so" is 32-bit instead of 64-bit" error. As @rbox suspected, dropbear seems to be creating the appropriate shell upon connect now on a 64-bit system (aftv2).
Unfortunately, I'm still receiving the "dispatch_protocol_error":
Code:
dispatch_protocol_error: type 51 seq 6
[5761] Jan 04 19:47:46 Exit (root): Child failed
Connection to 192.168.1.213 closed.
Any thoughts on this one @jocala? Googling dispatch_protocol_error type 51 returns zilch.

Fixing stock kernel sources for H30-U10

Github repo: https://github.com/kernel-killer/android_kernel_huawei_h30u10
All changes I made since last commit are in my private repo.

Install packages (Not sure if it's right):
Code:
sudo apt-get install build-essential
Note: Please run ./mk ckeck-env to verify your build enviroment (Newer GNU MAKE will fail but the code compiles the same with new or older version)
Build:
Code:
./mk bm_new k
Testing your new kernel:
Download both attachments (KernelSwapper and BootimgRestore).
Append headers from stock kernel to zImage (which can be found at ./out/target/product/huawei82_cwet_kk/obj/KERNEL_OBJ/arch/arm/boot/zImage)
In KernelSwapper update 'kernel' with your own generated zImage rename it to 'kernel' and replace it inside zip.
In BootimgRestore replace 'boot.img' with your current ROM's boot.img in case that something goes wrong (e.g.: Phone not booting).
Copy the two new zips into phone's memory (or SD card) and flash KernelSwapper.

===== Reserved #1 =====

Thanks for the awesome work KK. I am on CM 13 3.4.67 kernel. Can i use this or do i have to be in stock rom for testing the kernal?
Sent from my Honor 3C using Tapatalk
---------- Post added at 06:12 AM ---------- Previous post was at 06:02 AM ----------
Update : Flashed the kernel, phone booted but felt laggish while using. I am still testing, will let you know what happens
Sent from my Honor 3C using Tapatalk

karkeankit said:
Thanks for the awesome work KK. I am on CM 13 3.4.67 kernel. Can i use this or do i have to be in stock rom for testing the kernal?
Sent from my Honor 3C using Tapatalk
---------- Post added at 06:12 AM ---------- Previous post was at 06:02 AM ----------
Update : Flashed the kernel, phone booted but felt laggish while using. I am still testing, will let you know what happens
Sent from my Honor 3C using Tapatalk
Click to expand...
Click to collapse
Yes, I'm sure that the kernel has multiple bugs. The phone may feel laggish because there is enabled low-level kernel debugging over UART.
Thank you for testing...

kernel.killer said:
Yes, I'm sure that the kernel has multiple bugs. The phone may feel laggish because there is enabled low-level kernel debugging over UART.
Thank you for testing...
Click to expand...
Click to collapse
You are welcome, wishint you good luck for further development
Sent from my Honor 3C using Tapatalk

Hi, tnx for The kernel
if i Update my kernel VPN bug in CM12.1 will fix?

hamadk said:
Hi, tnx for The kernel
if i Update my kernel VPN bug in CM12.1 will fix?
Click to expand...
Click to collapse
Nope, it's ROM bug not a kernel bug plus I have released only development preview version which has enabled many debugging options and it may be quite buggy.

Thanks, but can this process led to a suitable kernel for CM13?

Does this kernel fixes the video playback problem and the recording problem?(Can't play or capture 720p videos, screen recorder works fine, just the camera.)
Sent from my Huawei Honor 3C using XDA Labs

Lumpbloom7 said:
Does this kernel fixes the video playback problem and the recording problem?(Can't play or capture 720p videos, screen recorder works fine, just the camera.)
Sent from my Huawei Honor 3C using XDA Labs
Click to expand...
Click to collapse
http://forum.xda-developers.com/showpost.php?p=67848925&postcount=8

mhxygh said:
Thanks, but can it this process led to a suitable kernel for CM13?
Click to expand...
Click to collapse
Aim of this project is to make stock kernel sources stable for KitKat ROMs (It is originally for KK) but somebody else may patch them for CM 13. I am not working on this nor I'll do.

Will you be adding extra CPU governors and IO schedulers along with kernel level wakeups for double tap waking?

I was wondering who else is developing kernel 3.10.XX for this device ?

Ms_Julia said:
I was wondering who else is developing kernel 3.10.XX for this device ?
Click to expand...
Click to collapse
Actually, nobody is working on 3.10.X kernel. And I'm rather focusing on LineageOS for now.

What is the defconf for our device in kernel source

imranpopz said:
What is the defconf for our device in kernel source
Click to expand...
Click to collapse
This should include most configs
Code:
/* Mediatek common */
./mediatek/config/common/autoconfig/kconfig/AEE
./mediatek/config/common/autoconfig/kconfig/USER
./mediatek/config/common/ProjectConfig.mk
/* MT6582 common */
./mediatek/config/mt6582/autoconfig/kconfig/platform
./mediatek/config/mt6582/ProjectConfig.mk
/* h30u10 device specific */
./mediatek/config/huawei82_cwet_kk/autoconfig/kconfig/project
./mediatek/config/huawei82_cwet_kk/ProjectConfig.mk

kernel.killer said:
This should include most configs
Code:
/* Mediatek common */
./mediatek/config/common/autoconfig/kconfig/AEE
./mediatek/config/common/autoconfig/kconfig/USER
./mediatek/config/common/ProjectConfig.mk
/* MT6582 common */
./mediatek/config/mt6582/autoconfig/kconfig/platform
./mediatek/config/mt6582/ProjectConfig.mk
/* h30u10 device specific */
./mediatek/config/huawei82_cwet_kk/autoconfig/kconfig/project
./mediatek/config/huawei82_cwet_kk/ProjectConfig.mk
Click to expand...
Click to collapse
Replace Device Name with the configuration file found at:
Source/arch/arm/configs
It's written in this way something_DeviceCodename_user_defconfig
I need for the above step.. ☝☝☝

imranpopz said:
Replace Device Name with the configuration file found at:
Source/arch/arm/configs
It's written in this way something_DeviceCodename_user_defconfig
I need for the above step.. ☝☝☝
Click to expand...
Click to collapse
Well... This is Mediatek, DO NOT expect the sources to look nice. The configs are scattered through ./mediatek subdirectories, *.mk files are parsed and configs are assembled during build. Unfortunatelly, even if you manually assemble .config you will NOT be able to build the kernel. It is full of dirty hacks (Mediatek) and just typing "make" won't work, build will break.
Build:
Code:
$ git clone https://github.com/kernel-killer/android_kernel_huawei_h30u10.git
$ cd android_kernel_huawei_h30u10
$ export ARCH=arm && export ARCH_MTK_PLATFORM=mt6582 && export TARGET_PRODUCT=huawei82_cwet_kk
$ export CROSS_COMPILE=/path-to-your-toolchain/.../bin/arm-linux-androideabi-
$ ./mk n k
Code:
$ ./mk -h
Usage: (makeMtk|mk) [options] project actions [modules]
Options:
-t, -tee : Print log information on the standard-out.
-o, -opt=bypass_argument_to_make
: Pass extra arguments to make.
-h, -help : Print this message and exit.
Projects:
one of available projects.
Actions:
listp, listproject
: List all available projects.
check-env : Check if build environment is ready.
check-dep : Check feature dependency.
n, new : Clean and perform a full build.
c, clean : Clean the immediate files(such as, objects, libraries etc.).
r, remake : Rebuild(target will be updated if any dependency updats).
mrproper : Remove all generated files + config + various backup files in Kbuild process.
bm_new : "new" + GNU make's "-k"(keep going when encounter error) feature.
bm_remake : "remake" + GNU make's "-k"(keep going when encounter error) feature.
mm : Build module through Android native command "mm"
mma : Build module through Android native command "mma"
emigen : Generate EMI setting source code.
nandgen : Generate supported NAND flash device list.
codegen : Generate trace DB(for META/Cather etc. tools used).
drvgen : Generate driver customization source.
custgen : Generate customization source.
javaoptgen : Generate the global java options.
ptgen : Generate partition setting header & scatter file.
bindergen : Generate binder related information
sign-image : Sign all the image generated.
encrypt-image : Encrypt all the image generated.
update-api : Android default build action
(be executed if system setting or anything removed from API).
check-modem : Check modem image consistency.
upadte-modem : Update modem image located in system.img.
modem-info : Show modem version
gen-relkey : Generate releasekey for application signing.
check-appres : Check unused application resource.
sdk : Build sdk package.
win_sdk : Build sdk package with a few Windows tools.
banyan_addon : Build MTK sdk addon.
banyan_addon_x86 :Build MTK sdk x86 addon.
cts : Build cts package.
bootimage : Build boot image(boot.img).
cacheimage : Build cache image(cache.img).
systemimage : Build system image(system.img).
snod : Build system image without dependency.
(that is, ONLY pack the system image, NOT checking its dependencies.)
recoveryimage : Build recovery image(recovery.img).
secroimage : Build secro image(secro.img).
factoryimage : Build factory image(factory.img).
userdataimage : Build userdata image(userdata.img).
userdataimage-nodeps
: Build userdata image without dependency.
(that is, ONLY pack the userdata image, NOT checking its dependencies.)
dump-products : Dump products related configuration(PRODUCT_PACKAGE,PRODUCT_NAME ect.)
target-files-package
: Build the target files package.
(A zip of the directories that map to the target filesystem.
This zip can be used to create an OTA package or filesystem image
as a post-build step.)
updatepackage : Build the update package.
dist : Build distribution package.
Modules:
pl, preloader : Specify to build preloader.
lk : Specify to build little kernel.
md32 : Specify to build DSP md32.
tz, trustzone : Specify to build trusted execution environment.
k, kernel : Specify to build kernel.
dr, android : Specify to build android.
NULL : Specify to build all components/modules in default.
k <module path>
: Specify to build kernel component/module with the source path.
dr <module name>
: Specify to build android component/module with module name.
Other tools:
prebuilts/misc/linux-x86/ccache/ccache -M 10G
: Set CCACHE pool size to 10GB
Example:
./mk -t e1k emigen
: Generate EMI setting source code.
./mk -o=TARGET_BUILD_VARIANT=user e1k n
: Start a user mode full build.
./mk listp : List all available projects.
./mk e1k bootimage
: Build bootimage for e1k project.
./mk e1k bm_new k
: Build kernel for e1k project.
./makeMtk e1k c,bm_remake pl k
: Clean & Build preloader and kernel for e1k project.
./makeMtk e1k n k kernel/xxx/xxx
: Build(full build) kernel component/module
under the path "kernel/xxx/xxx" for e1k project.
./makeMtk e1k r dr Gallery
: Rebuild android module named Gallery for e1k project.
./makeMtk e1k mm packages/apps/Settings
: Change Directory to packages/apps/Settings and execute "mm"
./makeMtk e1k mma packages/apps/Settings
: Change Directory to packages/apps/Settings and execute "mma"
Edit:
I fixed the sources, so menuconfig can be used.
Apply patch:
Code:
$ git am 0001-Fix-build-using-make-command.patch
Build:
Code:
$ cd kernel && export ARCH=arm && export ARCH_MTK_PLATFORM=mt6582 && export TARGET_PRODUCT=huawei82_cwet_kk
$ export CROSS_COMPILE=/path-to-your-toolchain/.../bin/arm-linux-androideabi-
$ make -C $(pwd) O=output h30u10_defconfig menuconfig
$ make -C $(pwd) O=output
Append MTK headers:
Code:
$ ../mediatek/build/tools/mkimage output/arch/arm/boot/zImage KERNEL > output/zImage
*Note: I recommend using AOSP arm-linux-androideabi-4.9 toolchain.

Getting cp: cannot stat 'out/target/product/huawei82_cwet_kk_kernel.log
Make [1]: [kernel ] error 1
Make: *** [remake] error 2