yashsingh1/xdaforums huggingface dataset:
[XPERIA X10 Android Development] biktor_gj:
Yes there is! unless you delete all the /bin & /lib folders from mtdblock2, that is. If you remove it init can't link the logger, so there are no logs, the same way, if you remove the shell or change the permissions to the sh binary (well the sh symlink), when you try to do an adb shell it'll either show up "permission denied" or simply return to your shell instead of phone's shell.

So, about the rest of the things:

suf: Related to the MCPU, it seems to start the MiscTA service, as pointed by goroh some time ago. I think this is part of the reason why the kernel crashes on boot after the miniloader. If you attempt to run it manually it'll say "ONCRPC Task already started" several times. I think it's one for each rpc channel (but not sure).

cmzn: seems to set some system properties, presumably a helper of some kind, but no accurate idea of what it it's use. If you hexedit it you'll see some libraries linked to it, and some things that look like used for logging. Though I'm pretty sure I've seen something related to it on the kernel source, but would need to take a look.

About unmounting /system. Short answer: possible with miniloader, impossible on stock.

Long answer: as init mounts the system partition and tries to run the servicemanager from there and attempts to restart it everytime it crashes, if you try to unmount it it will be busy, either because it's running, or because it's restarting. If, through miniloader and custom initrc, you take all that crap out, you can unmount and do whatever you want :) but it's init what's locking it in place.

When you have some time, please take a look at the latest kernel source from SE. As they're backporting parts of the code from eclair to donut, you can see where we are going. It seems we'll be able to charge the phone while powered off at last! yippie!

You can't boot a froyo rom on a 1.6 kernel. You can't even, on first approach at least, boot a froyo rom from a 2.1 kernel. I'm using my i9000 for tests (that's part of the reason why I bought it), and init scripts are way too different, and there are some capabilities missing on the kernel itself. That doesn't mean everything is lost ;)

EDIT: For the 10th time, fastboot is a protocol created from Google if I recall, and Acer and HTC uses. SonyEricsson doesn't use that protocol, neither does Samsung, for example. So no, there's no fastboot, and no, it won't be fastboot, at least for a long time...
[XPERIA X10 Android Development] SuperUserMovado:
help

Hi I am interested in getting this project moving along. I am currently taking an operating system design course. I am new to android hacking. Can any of you provide instructions on how you take over the operating system at boot.

Such as the instructions you run at boot or scripts you run before rebooting the system. Or is this done via adb while the phone is up. Just a simple tutorial showing the steps would help people who want to help developers test new things, or even just boot their own linux os with the SE's current kernell.
[XPERIA X10 Android Development] zdzihu:
I'm copying Froyo's system over SE's one, there is an sh binary, and it's 777. Still, I can't access shell, as you mentioned I'm getting "simply return to your shell". After several seconds it reboots.

Maybe I'll try with symlinked sh...

I actually managed to mount my ext2 image as /system without unmounting the original one. But all I've got was segfault on any operation (kinda obvious) :)

I saw that! Happy days! Also, there are some parts ported from Froyo kernel :)

I am aware that it won't boot by simply replacing files. But here's what I want to do:

1. Replace /system with custom one

2. Start normally and pray it gets through to reach services section. If you see the init.rc from the very top to the services section, there's nothing that possibly could stop me from booting.

3. exec drm.sh and replace init files with my own ramdisk.

3. Chroot into / !

4. ???

5. Profit :)

I just need logcat and dmesg to see what's going on there...

Cheers!
[XPERIA X10 Android Development] ratheen:
so,

Just a thought here, I was looking over some progress that was made to port Android over on the HD2 and they used a launcher "HArret" to launch the linux / Android OS.

just a thought here:

would it be possible to just launch an APP that clears the memory and re-loads an OS?

even though the main os is 1.6 or 2.1 (after it's released) may be we can just load another 2.2 over it?
[XPERIA X10 Android Development] biktor_gj:
Hey, if I quote your quotes with my quotes this is going to get messy, so I will just point some things out and see if it helps :)

If you only get back to your shell, it's a problem with permissions. You changed the permissions on the binaries, but probably not on the directory itself. Try this:

busybox chown 0.2000 /system/bin -R

busybox chmod 7777 /system/bin -R

busybox chmod 6755 /system/bin/busybox

busybox chmod 6755 /system/bin/sh

Now you have suid busybox, and it should really run. The reason for setting the group to 2000 is to allow adb to execute it, since ro.secure is set to 1. By the way, it's rebooting because servicemanager is crashing, probably because it doesn't have correct permissions either. I actually got servicemanager running, but the dalvik vm crashes all the time, so it doesn't reboot by itself, but it doesn't work anyway...

Now, about the 'froyo' problem: There are some dependencies which rely on the kernel. Some of them are these:

# Directory for putting things only root should see.
mkdir /mnt/secure 0700 root root

# Directory for staging bindmounts
mkdir /mnt/secure/staging 0700 root root

# Directory-target for where the secure container
# imagefile directory will be bind-mounted
mkdir /mnt/secure/asec 0700 root root

# Secure container public mount points.
mkdir /mnt/asec 0700 root system
mount tmpfs tmpfs /mnt/asec mode=0755,gid=1000

# Create cgroup mount points for process groups
mkdir /dev/cpuctl
mount cgroup none /dev/cpuctl cpu
chown system system /dev/cpuctl
chown system system /dev/cpuctl/tasks
chmod 0777 /dev/cpuctl/tasks
write /dev/cpuctl/cpu.shares 1024

mkdir /dev/cpuctl/fg_boost
chown system system /dev/cpuctl/fg_boost/tasks
chmod 0777 /dev/cpuctl/fg_boost/tasks
write /dev/cpuctl/fg_boost/cpu.shares 1024

mkdir /dev/cpuctl/bg_non_interactive
chown system system /dev/cpuctl/bg_non_interactive/tasks
chmod 0777 /dev/cpuctl/bg_non_interactive/tasks
# 5.0 %
write /dev/cpuctl/bg_non_interactive/cpu.shares 52

Without some of them it might boot, but without any of it it crashes. Or so I think :)

I tried doing the 'droid' way too, but didn't succeed, maybe you're luckier than me. Anyway, I think it's easier to just end up the boot process without chrooting. I mean, instead of restart all the init sequence, just put whatever is missing on the drm script and let it boot all the way. While servicemanager crashes the first time, init should have enough time before restarting the service to run the drm script, hence finishing whatever was needed to allow servicemanager to run properly. I'm not saying will work, but there's a chance ;)

Hope it helps!
[XPERIA X10 Android Development] zdzihu:
Thanks a million Biktor, now I can use shell!

I replaced sh binary with symlink/bbox.

I avoided servicemanager crash by replacing it with symlink to / (where I unpack real servicemanager later).

As expected, for now zygote crashes and loops. But no more reboots. Going good!

But here's another problem - any binary file I try to launch from the shell gives me segfault (so obviously still no logcat). All I can use is busybox.

Would that be also related to permissions? or rather to lack of real sh binary? With logcat working I could troubleshoot that damn java :mad:
[XPERIA X10 Android Development] biktor_gj:
Segmentation faults have a reason too, it will probably be a problem between new libraries and the toolbox binary. At least on typical shell commands. You might also be missing links to getprop & setprop... Sometimes they get messed up when you copy them from a vfat partition.

Do a busybox ls -l on /system/bin

Look for the symlinks for toolbox (chmod, ls etc)

Also check the permissions on the lib directory and make sure they are correct (and the directory itself)

Want me to take a look?

EDIT: Forgot to say, ease your life a little bit: /system/bin/busybox --install /system/bin

:)
[XPERIA X10 Android Development] zdzihu:
Yep I have all symlinks correct. Tried many permissions to /system, /lib etc. but no joy. It's not just toolbox that's giving segfaul, all of the binaries do.

At least I'm finally running ADB shell as root so I can do all changes live (flashed +- 30 times today before I fixed that). :D

I could fully replace toolbox with busybox, but bb doesn't seem to have getprop setprop. Going to look into toolbox sources now, maybe I could compile multi-all-in-one-box ;)

I'll PM you a package later on today.

Cheers!

EDIT: Tried sdk=4 and sdk=8 in build prop but no luck. Something tells me that the problem is related to shell provided by busybox (somehow all services start without problem so not likely a /libs problem). But damn, it's so amazing when you can auto-complete commands with tab :D
[XPERIA X10 Android Development] Bin4ry:
I recompiled and tryed to correct some usbloader issues.

I tryed to activate full fastboot support. Due time lack i cannot try it myself but i will share it with you :D

Maybe it helps maybe not.

To try just do it like ever

insmod splboot.ko

cat fastbootloader > /proc/splboot/image

echo > /proc/splboot/boot

it will go directly to fastboot mode and you should be able to connect through fastboot.

Regards

Bin4ry

EDIT:

I also recompiled io_ex.ko to try to fix some issues.

Here you go:

insmod io_ex2.ko

cat /proc/splimage > /data/spldump.bin

I hope this dump bootloader correctly.
[XPERIA X10 Android Development] thor2002ro:
I tried your instructions and here is the resulting bin

I checked it with a hex editor and i don't think it went pretty good... a lot of FF

the file is 1024kb big...
[XPERIA X10 Android Development] zdzihu:
Thanks Bin4ry, will look into it asap.
[XPERIA X10 Android Development] biktor_gj:
Important part is the first 128kb, and from those, the first 50k which are the actual bootloader. The file is fine :)
[XPERIA X10 Android Development] Stryker777:
Do you all know where I can get the arm-gcc toolchain for gcc 4.4.3? Sorry, don't use windows or have a machine in the house to desecrate.

Thanks.
[XPERIA X10 Android Development] maxrfon:
Someone, who deleted messages regarding disassembling the spl, could you please explain why you delete it?

We respect rules and there was nothing wrong with my post.

Please, fill yourself home :)

And regarding the topic:

SPL dump, a few topics before is not full. It looks like the rest memory is read protected, so further analysis is not possible.

Any other ideas?
[XPERIA X10 Android Development] Bin4ry:
Why do you think its not complete? Here is my dump, as you see after Offset 2421 there is my recompile of fastbootloader.

So i think there is no protection or am i getting something wrong?

@All others:

We tryed this methods before. Thats what splboot and chrooting about :)

Regards

Bin4ry
[XPERIA X10 Android Development] maxrfon:
Ok, thanks!

So any hint about the start address for disassembler??

I can try right now to decompile it, as i have some good tools for it ;)
[XPERIA X10 Android Development] Bin4ry:
Thats the problem i have too atm. I thought about reconstruct to ELF or smth.

BUT i have no idea. All Entry points that i know was failing. Maybe we have to run it in qemu or smth to look what happens. As far as i know goroh had compiled a qemu for X10. I can't find it now but i thought it was there ^^

Regards

Bin4ry
[XPERIA X10 Android Development] maxrfon:
I really think there are some pages missing because i disassmed the file and still i see one page has strings but there are no address links to the strings.

i assume the start address is 98000 as it fits the other constants links.. But the strings are not linked.

Checking one more time..

EDIT:

Checked and now i can surely say the spldump contains some data from the spldump itself, but it's just uncleared RAM after booting the phone..
[XPERIA X10 Android Development] biktor_gj:
I think I have the modified qemu at hone and the.source patches if you want them. We tried to use it with the flash loader but not with the bootloader...

Btw, residual data from spldump is actually part of the shared memory from the mcpu.. (all those proxy strings and stuff)

On a side note, Im still trying to.find the correct pinout for the jtag connector. Anyone has a better idea than measuring voltages and blind guessing the pins until it works? :)
[XPERIA X10 Android Development] Bin4ry:
I will look again in sources. Goroh made the first io_ex2.ko based on msm. I think i should try to compile it to another one. Worth a try!

That would be really nice :)

Thanks mate

Regards

Andreas
[XPERIA X10 Android Development] maxrfon:
So even if we get the spldump, as far as i know, SE uses signatures to sign the flash content and it checks it against it's own algos. The only method to cheat it is to find an exploit to bypass the checks, but atm it's not possible.

Btw, we call it BootLoader, the software that resides in mem and accepts external loaders to do mods to the memory.

So the sin headers are the signatures. I tried to force msm to enter download mode (it's in the qcom's core, so SE can't lock it) but the phone reboots at once.

EDIT: WRONG :) It's Bin4ry modification :)

"Although i see inside the spl "QPST download mode".. So it uses normal qcom dwonload mode at the end."

But i still believe there is a way to overwrite or load custom bootloader(spl), and this is what would be nice to be heading towards.
[XPERIA X10 Android Development] Chewitt:
Just to let you know no one delete your posts, the XDA forum had an error during maintenance and so had to revert back to a backup from 24h ago.
[XPERIA X10 Android Development] maxrfon:
Thanks, i've been told about that.
[XPERIA X10 Android Development] biktor_gj:
That's why I'm trying again to find the correct jtag pinouts. But, there are a lot of problems:

First, it's not only one check on the bootloader what has to be bypassed.

This is more or less the boot procedure, for what I've seen (this is my best guess)

Bootloader start

__sysinit__

--> back key pressed? y/no

yes -> start usb, send greeting string, wait for ack & flash loader

------------> send loader. Check signature. Correct? boot to flash loader. Incorrect? halt.

no -> previous boot was for flashing? yes -> check signatures, and sum of the images. If any fail -> recovery. If recovery is corrupt -> halt.

previous boot was for flashing? no -> check signatures. Correct? yes-> boot no -> recovery.

Note it doesn't matter if you actually flashed something or not. If you attempted to but failed (security error, file corrupt, communication lost while sending data), it goes to recovery as it looks to it as a bad flash, even if you didn't even write a single byte to it.

That's for the stock acpu bootloader. mcpu loader should be there, but it's locked. No one has been able to put the mcpu in download mode. Goroh got to put it into diagnostic mode by "ruining" the mcpu driver on the kernel (there are some options there to force it) (ruining not in a bad way, but breaking the ability to use the modem in a normal way). You can get some more data thanks to it, but not download mode. It would be great to be able to boot qualcomm's SBL for the Surf board, but I haven't been able to even find it.

There is sample code for qsd8k architecture start (from code aurora mostly). Usbloader uses part of this, but nobody knows if it can cold-boot the device. We only did a kexec jump to it, but the system is already intialized (and mmu, caches, i2c, etc.). I'd love to be able to boot that loader through jtag, but need to find the correct pinout first. Well, that, and find a way/software to actually connect to it once I find the pinout.

And, last but not least, in the case we get to cold boot our own bootloader, write it to flash, and not break too many things in the process, the loader calls the mcpu to make it start booting, and we don't know how to do that. It could be done on a hardware level, but I think it doesn't, I think it's called from the S1 Loader, since otherwise, the mcpu would crash when attempting to flash, since the OS in there would already be in use. And, when running from recovery, one of the things it does is stop the mcpu code. But not certain if it really does that or just close RPC channels. Of course there'll be a command to stop it without rebooting, but we haven't found a way either.

And god help us with the TA, IMEI, Simlock etc.

Pretty good mess, huh?

EDIT: Here is qemu :) The file called 13-Bootloader is the second flash loader (loader.sin)
[XPERIA X10 Android Development] maxrfon:
Hi!

Yes, it's a pretty hard task but i am sure it's possible, since if you can run anything your own in the memory - you can reconfigure everything manually and start the QC Bootloader.

It's pretty tough way, but then we will face another problem: Simlock is using almost same way to get signed by EMMA server, that's why there is no single standalone unlocker up to now! They use some 2l, (dont wanna advertise the guys) and even this very 2l uses emma server to sign the simlock thing.

I still believe the qcom's amss runs without any checking, since (i might be wrong) there is no internal signature check in Qcom's mcus, so patch would make us free :)

But let's get back to the loader and it's side wide tasks...

JTAG: Ok, you will get the spl in case if the pins are ON(!) and if they present in the hardware..

I managed to disassemble the normal loader, that emma uses - there is no overload exploits, no stack overflow, no way to do anything with the signature address(needs 2 be checked 1 more time) to fool the signature address and point the whole checking bunch to an additional data, sent after the bootloader (just to fool it and force to check non-patched bootloader, but it depends then on the start address that will be used to execute the loader.

So that maybe will help.

What i mean in total - we need to study the emma's bootloader and the way it loads and executes.

SimLock: i managed to read and write the 7da block, along with others. But what really discouraged me is : i made backup before unlocking, unlocked my x10 and then wrote back the two "locked" blocks, that were changed and... the phone got tampered :)

Only when i wrote back the unlock blocks it started to work normal, so there are some tricks.. And so on..

So there is a lot of interesting things to do :)
[XPERIA X10 Android Development] maxrfon:
qemu

Btw, how to use this wonder by Goroh?

He's really nice and pitty he is not appearing again..

EDIT: I see the explanation but i hardly get the point..
[XPERIA X10 Android Development] livestockpimp:
hey all!

hey guys,

I have recently purchased one of these X10s and am so frustrated with the firmware and thought I might join the team here!

not really sure how much help I can be, essentially I work 9-5 as a Linux tech and I have basic programming skills although have never really played much with the mobile devices OS.

I guess if anyone wants to point me in some direction I am a fast learner and am happy to contribute time towards this cause or if there are any basic guides in relation to a little more understanding on these devices or if someone wants to PM me, ect on a basic start point.

I am not asking for A-Z training on this as I am sure I can pick it up from reading this thread but a start point and basic info would be nice before i start hacking away!
[XPERIA X10 Android Development] Mac_33:
+1, Same here, I'm in my final year Comp Eng (U of Toronto). I have experience in C/C++, Assembly and I'm currently working on my design project which is an Android application. I have taken several programming courses and courses on Operating systems and computer OS architecture (and hardware).

I have looked over this thread and my understanding is that we are not able to take the bootloader from the phone and are not able to reflash it either. Am I correct? And we can't use custom firmwares because the firmware needs to be signed by SE.

Please let me know if I am correct and if there is something I can do.
[XPERIA X10 Android Development] maxrfon:
It's good to have new & fresh brains :)

The task is easy - force the phone to accept new kernel.

The way you do it does no matter.

So welcome :)
[XPERIA X10 Android Development] JamesBarnes:
Good day to jump on the bandwagon i think...

Im a programmer by trade, although not much experience with linux beyond day to day usage.

Some basic questions:

Where on the phone does the kernal reside?

What specifically stops us writing to that area?

At what times does the phone have the ability to write to that area?

Thanks
[XPERIA X10 Android Development] Bin4ry:
My compiler is broken :/

Can somebody compile it against X10Donut source please ?

Regards

Bin4ry

@All who want help:

Just start and study X10 Kernel Source, also look at CodeAurora Forums and study USBLOADER, this is what Goroh portet to X10. You will see quickly what problems we have :) -> After you done this, start thinking with us :D

And thanks for the help :)
[XPERIA X10 Android Development] livestockpimp:
thanks,

i will have a look!
[XPERIA X10 Android Development] PheneoN:
Hey Guys,

Today i read the new about the HTC Desire bootloader that has been cracked.

Maybe you'll get some more information about the way they did it.

The website of the person who managed to crack the bootloader:

http://alpharev.shadowchild.nl/

I do not have any coding skills, don't blame me for spamming this thread, only trying in a way i can..
[XPERIA X10 Android Development] vegard_e:
I recompiled the io_ex2.ko for X10 Mini Pro and dumped the bootloader of my phone.

It is pretty similar to the X10 bootloader dump posted earlier, so it might be of interest.
[XPERIA X10 Android Development] Bin4ry:
Modemreset:

insmod ....

echo > /dev/reset_modem

Maybe useful.

Regards

Bin4ry
[XPERIA X10 Android Development] vegard_e:
May I have the sources for that? Perhaps also the fastbootloader and the module loading the fastbootloader.

U20i kernel won't load modules compiled for X10 kernel, and I want to join the fun. ;)

I've been looking through the bootloader dumps.

From what I can tell the bootloader performs some sort of initialization, and then jumps to either 0x20000000 or 0x20008000 (for U20i this is either 0x00200000 or 0x00208000).

I'm not sure what determines which address to jump to, it appears to have been replaced by a NOP. (Offset 0x2f0 in X10 dump, 0xe4 in U20i dump).
[XPERIA X10 Android Development] Bin4ry:
Sure you can have sources.

Here you go, hope you can help :)

Regards

Bin4ry
[XPERIA X10 Android Development] zdzihu:
Hi guys, I've already played with reset_modem module without any success. However, I've seen somewhere in sources that power management performs modem reboot in case mcpu can't be waken up from sleep state. But is that warm reset? Don't know. Maybe it's worth checking.

Anyway, I'll be back in 2 weeks when I get a laptop replacement.

Cheers!

Sent from my C64 using Datasette.
[XPERIA X10 Android Development] ucaboys:
After reading about the @Secure Flag - I would guess that the jump might have something to do here. But on the other hand I would also bet that the X10 has already initialized hardware and other process at this point - otherwise it wouldn't reboot when we try to mess with the SPL.

I might be wrong, what do you guys think?
[XPERIA X10 Android Development] Bin4ry:
SPLDump with IDB file for view in IDA Pro

Many thanks to vegard_e for giving the entry point and explainations :)

Hope you will help us more :)

Regards

Bin4ry
[XPERIA X10 Android Development] kloud_:
thank you bin4ry.. now i can also get started...!! :D :p
[XPERIA X10 Android Development] Umeaboy:
Just a quick question...... a friend of mine that works with computers at his own company offered himself to help cracking this bootloader........... what does he need to continue the already made work?

spldump?