yashsingh1/xdaforums huggingface dataset:
[XPERIA X10 Android Development] MrHassell:
mmcblk0p1 - mmcblk0

# more partitions

major minor #blocks name

31 0 4352 mtdblock0

31 1 113920 mtdblock1

31 2 361088 mtdblock2

31 3 476160 mtdblock3

179 0 7761920 mmcblk0 (3790 mb)

179 1 7757824 mmcblk0p1 (3788 mb)

# pwd

/proc

The /sys directory is an interesting one. Using Sysfs is a file system but is also mounted as /sys. The result is writing to memory like issuing commands. Proc for processes Dev for devices Sys for the system etc..

device/system/init/init.c allows for logging by macro. SE ripped this out and does not exist in many versions of Android, in release mode anyhow ;)

X10 - has /dev/block/ - notice the two unusual mounts - mmcblk0 & mmcblk01p1 - not sys / dev / cache.. so

what are they?

vold - mtdblock3 - mtdblock2 - mtdblock1 - mtdblock0

loop7 - loop6 - loop5 - loop4 - loop3 - loop2 - loop1 - loop0

ram7 - ram6 - ram5 - ram4 - ram3 - ram2 - ram1 - ram0

vold is the volume daemon. Interesting in that this replaces /dev/socket/mountd - which would in any unix domain socket, makes a normal scenario.

/dev/socket/vold/vold - this is where the root ends in visibly of the X10 firmware. Beyond this point is virtual memory.
[XPERIA X10 Android Development] ardf69:
mmcblk0 is the microSD and mmcblk0p1 is the partition in the microSD mounted by vold.

Ciao Angelo
[XPERIA X10 Android Development] xnewser:
Apri sta minchia di bootloader ci si stanno a congela le palle a forza di aspettare.

Robert Dupalle

MOD EDIT: USE ENGLISH LANGUAGE
[XPERIA X10 Android Development] Mr. Clown:
@xnewuser

Eventhough you didn't meant what you say. Don't use foul language. First and Final Warning.

@ all

Back to topic please.

Thanks
[XPERIA X10 Android Development] 28spawn:
anyone has checked kernel\drivers\mtd\devices\msm_nand.c ???

This is one of the files that SE edited maybe there is anything usefull to we find the boot partition
[XPERIA X10 Android Development] MrHassell:
mtdblock0 - /dev/

I took a look in the new source for Play, Neo and Arc and found something worth sharing, I guess? More investigating is required in these files but the specific location is;

glen@xda:~/bin/Xperia_Play_3.0.A.2.181_182/kernel/drivers/mtd/nand$ ll
total 832
-rw-r--r-- 1 glen glen 16215 2011-02-26 02:44 alauda.c
-rw-r--r-- 1 glen glen 5978 2011-02-26 02:44 ams-delta.c
-rw-r--r-- 1 glen glen 15147 2011-02-26 02:44 atmel_nand.c
-rw-r--r-- 1 glen glen 1412 2011-02-26 02:44 atmel_nand_ecc.h
-rw-r--r-- 1 glen glen 14821 2011-02-26 02:44 au1550nd.c
etc... there are a lot of drivers here!

This to me appears there are different nand versions in place AND the Makefile is where they are setup as expected.

#

# linux/drivers/nand/Makefile

#

obj-$(CONFIG_MTD_NAND) += nand.o nand_ecc.o

obj-$(CONFIG_MTD_NAND_IDS) += nand_ids.o

There are too many to print out here but these are not telling us anything they are just setting up the hardware to handle nand memory. However poking around in here I did find one file that was of interest.. redboot.c

/*

* Parse RedBoot-style Flash Image System (FIS) tables and

* produce a Linux partition array to match.

*/

#include <linux/kernel.h>

#include <linux/slab.h>

#include <linux/init.h>

#include <linux/vmalloc.h>

#include <linux/mtd/mtd.h>

#include <linux/mtd/partitions.h>

struct fis_image_desc {

unsigned char name[16]; // Null terminated name

uint32_t flash_base; // Address within FLASH of image

uint32_t mem_base; // Address in memory where it executes

uint32_t size; // Length of image

uint32_t entry_point; // Execution entry point

uint32_t data_length; // Length of actual data

unsigned char _pad[256-(16+7*sizeof(uint32_t))];

uint32_t desc_cksum; // Checksum over image descriptor

uint32_t file_cksum; // Checksum over image data

};

etc... there are a few interesting lines of code in here such as the expected RedBoot partition table offset..

printk(KERN_NOTICE "Searching for RedBoot partition table in %s at offset 0x%lx\n", master->name, offset);

We do however know the root - mtdblock0 - /dev/ - so I'm not sure why we just went around this but there is really some interesting c code in here :)
[XPERIA X10 Android Development] Blagus:
Isn't /dev/block/mtdblock0 actually /system, not root / ?
[XPERIA X10 Android Development] PoTi_96:
/dev/block/mtdblock2 is /system

And /dev/block/mtdblock3 is /system on x10 HD (correct me if i'm wrong but i have read it several times ago in an other thread)
[XPERIA X10 Android Development] Blagus:
I've seen in one of *.rc scripts in root kexec command to load kernel in case of kernel panic. Can we then load new kernel with -p option, produce kernel panic and execute newly loaded kernel?
[XPERIA X10 Android Development] Bin4ry:
Won't work this way, but thats 1 of 2 ideas i'm after at the moment :D

Maybe someone has an dev firmware with capk and capk-root in /usr/xbin/ ? If yes please share!

Regards
[XPERIA X10 Android Development] PoTi_96:
sorry i know it's dev only but how does someone get a dev firmware?
[XPERIA X10 Android Development] Blagus:
Somewhere on this forum there was thread with 2.0.1.x.x Customized RU developer FW.

BTW, nice to see you back here, Bin4ry, with some ideas ;)
[XPERIA X10 Android Development] jimbo77:
This Thread?

http://xdaforums.com/showthread.php?t=820315

Jim
[XPERIA X10 Android Development] wolfilein:
@Bin4ry if seend this files in the 2.1 test rom from x10 mini prototype.

http://rapidshare.com/files/424248203/System__updated_with_ADB_.rar
[XPERIA X10 Android Development] omnikam:
I'm new here but have been following for some time. Is it possible to use an existing working certificate but modify the content. Take a known.sin and modify the contents while leaving the certificate unmodified? Just an idea

When I was younger I used to do it to games at the machine code level, not really sure about these files though?
[XPERIA X10 Android Development] Blagus:
It has already been told milions of times that if that was possible it would be already done...
[XPERIA X10 Android Development] GreatBigDog:
I'm no security expert and I very well could be wrong but I believe that this is how it works. For the protected files the certificate is generated using SE private keys with RSA 1028 bit encryption. The phone contains SE public keys and is going to use these keys to check the file against the certificate. If they don't match, the phone won't boot.

Change anything in the file or the certificate and they won't match.
[XPERIA X10 Android Development] omnikam:
I see, is it possible to trace the boot sequence of a given rom, say in virtual memory via an emulator, then dump the memory for investigation? At some level a security check is either positive or negative, maybe intercepting that point would be of great value? Just some ideas :)

Doesn't SE supply an emulator for testing purposes?
[XPERIA X10 Android Development] MrHassell:
2048 bit - otherwise exactly!

sent from heaven via x10a custom
[XPERIA X10 Android Development] MrHassell:
That's not going to help. The phone is what we need traced and it has been done. Check Bin4ry earlier posts, he provided this :-)
[XPERIA X10 Android Development] exsulis:
From another thread but still relevant

Just like hard modding a xbox to find how it worked to eventually soft modding one. The same principle would be applied here.
[XPERIA X10 Android Development] PoTi_96:
so me and the other guy are maybe right? what if it is so? then it's fking hard to open it for all xda's 0o ?
[XPERIA X10 Android Development] Blagus:
If you know how to hack it on HW level, go and do it. Everyone can disassemble it... you need the tools and knowledge to hack it...
[XPERIA X10 Android Development] MrHassell:
replace eprom

Beside the fact this phone is retailing quite cheap and at the end of it's life cycle now (coincidence?) can you really see this chip mod being for one easy to make, cheap to manufacture and easy to fit to the circuit?

Exploit needs complete understanding to add to a circuit! Good thing about this bootstrap process is if one key was compromised, another could be issued and the whole process would have to start again, hack has to be above the crypt channel or else the drm will just re-issue and waste any work and this is initiated from eprom...

You are in the right node as software is pointless even if a certificate was compromised, it could be instantly revoked / black listed, the crypt needs to be broken in eprom - boot.sin has been signed to meet the request from eprom.. replace xperia eprom from another device and bypass sanity checking.. that could work.
[XPERIA X10 Android Development] Blagus:
I think that we would have to completely erase EROM area in order to get rid of all DRM Marvin, O-something, Malbolge, Dante's Hell stuff and just make a small loader which would contain SE signature just to satisfy ROM's verification and we could do anything then... Because I don't think we can do much with all this checks, DRMs, red/brown certificates, virtualisations, RSA keys, locked recovery and boot....... I think that army uses less protections than this phone has got in one place... :S
[XPERIA X10 Android Development] PoTi_96:
i don't know anything on HW level :o

the only thing i was doing was cracking my psp not more..

btt... so can someone take a look (again) on the hardware?

or skip it if someone can confirm there's nothing...

so you won't see me in this thread for a while cause it's dev only....
[XPERIA X10 Android Development] Bin4ry:
Hmm,

i had another idea like i said before. But i think it cannot be done. If someone else want to try:

Get ksplice and compile it against kernel. Make the diffs and try to load the module onto running kernel.

But it seems that automatic mode does not work because there are too much changes from actual kernel to eclair kernel.

Maybe someone of you is more lucky with ksplice :D

For kexec again: As i see we have too much problems here.

I!!!! think ksplice or the kexec-module way is the only thing we can do (except Jtag and hardcore disassembling :P)

Regards

Bin4ry

P.S.:

I think that it's time to sell my X10. This device is too much outdated now and i want something new to play :P Sorry for that :D

Any ideas for a new device? Nice would be something with Hardware keyboard :D
[XPERIA X10 Android Development] Nikhil_007:
Hi all, may b some help... i have already tried jtag.. spoke to max the other day.. no luck... there is a thread somewhere about jtag diagram pic.. but trust me its heavily hashed everywhere.. even ma. Abandoned it coz even if v would hav rchd recovery even that was hashed..but to sum up.. u dont hav access thru jtag.. i already fried a motherboard trying that.. got d ph replaced...

X10i Android 2.1 + JIT...
[XPERIA X10 Android Development] ardf69:
ksplice is useless if there are changes in data structure. Theorically you can use it but you must provide the code to normalize the data structures for the new kernel too. Instead it could be used to apply little patches to the kernel.

Ciao Angelo
[XPERIA X10 Android Development] Nikhil_007:
i dont think it can be crackd..

There is more to it..which i found out after my discussion with max..

all is signed

ALL including recovery (yes it has one) too

max did found how to disable the MPU

but even recovery is signed and it's being checked by internal cpu's firmware. more on, start address to jump in the code is the start address of the code part from where it should start calculating hash

yes, resetting modem gives you a few milliseconds but then it locks the code is partially from htc. It has 0:SIM_SECURE and so on

but the code is accessible (i mean to unlock phone)

it's heavily hashed when you call to read the 07da

block

but if you disable mpu you can see it clear

a bit mangled but easy to recover.
[XPERIA X10 Android Development] Bin4ry:
Thanks to Z,Goroh etc.

I tryed a little with Z latest kexec_kit. Tryed to force modem to reset and not to crash.

You can see kmsg in /proc/last_kmsg

Regards

Bin4ry

EDIT:

Step forward or backward? Decided yourself oO

last_kmsg:
[XPERIA X10 Android Development] booyaga:
How hardcore? i dont mind picking it Down to atoms if theres a good chance of cracking it, and i do have a soldering Iron:) so where would One start? any idea?

Edit: and i do have Some general Knowledge on a Circuit Board works:p

Sendt from My cm6 x10 - xda app
[XPERIA X10 Android Development] :
original unlock code is hashed using salted sha-256.

unlock code is 16 random digits.

using available bruteforce tools, you can recover no more than one code in ~70 hours using ~200 pc with powerful gpu...

and - mpu and simular things have no ANY relation to simlock and entire s1 engine.

yes.

MrHassell writing here crap about marvin and so on drm things, like semcboot keys can be revoked in any time and so one.

that is total bs and crap.

semcboot have two pairs of keys, HARD-CODED, can't be changed or revoked, - developer and retail one, which are used to check different firmware parts.

which set to use determined by one from qFuse ( one time programmable bits on mcu, which determine its behavior )

we can OVERRIDE keyset on retail phones with specific bit in hwconfig ( security block, where things like IMEI, AIDs ( security version numbers ) for loaders,etc are stored )

however, there is a little problem - hwconfig signed by s1_hwconf key, which is "only" 1024-bit long
[XPERIA X10 Android Development] XperianPro:
hwconfig is checking are the sins signed if first test fail the phone its calling hwconfg to make test 2 test 3 test 4 but when is hwconfg disabled or moded somehow the boot is continued.

Is that little problem real little or is real big?
[XPERIA X10 Android Development] Blagus:
This means that unlock code CAN be retrieved on Red S1 phone and bruteforce-cracked to reveal standard 16 digit code?

I knew that, S1 security simply rounds Android system, right?

But how then maxrfon and/or Bin4ry get r/w access to flash when MPU is reset?

Do you mean TA - Trim Area?
[XPERIA X10 Android Development] MrHassell:
last post

Yes and yes - while rebooting and as zdzihu previously reported kexec is viable.

http://xdaforums.com/showpost.php?p=8714275&postcount=407

zdzihu

override partition table using kernel command line. Tried (via kexec) and it worked.

mtdparts=msm_nand:0x00440000@0x3fbc0000(appslog),0x06f40000@0x38c80000(cache),0x160a0000@0x05ae0000(system),0x1d100000@0x1bb80000(userdata),0x0001FFFF@0x00000000(loader)

Bin4ry - tawrite - http://xdaforums.com/showpost.php?p=8931422&postcount=442

cat /proc/mtd

mtd0 cache

mtd1 appslog

mtd2 userdata

mtd3 system

My final post on the subject. Have better things to do now the media have landed au reviour.
[XPERIA X10 Android Development] Blagus:
Dump what to find unlock code? Loader partition?

I know that, this function is also available in other tools (SEtool, Omnius), but we can't write to security zone of TA because it's hashed and signed. Further testing might be possible in BOOTROM mode, and UART pins might be connected to headphones jack (proved to be incorrect).

What's the problem?
[XPERIA X10 Android Development] MrHassell:
I can't stay away from this subject. Way too interested in it and I think we are very close now. Does anyone know the memory type, exact speed? Manufacturer, model and most important speed and timings?
[XPERIA X10 Android Development] mayank.1love:
I think MrHassell is completely correct about the Marlin DRM in X10. Sony has previously used Marlin DRM in PS3 and PSP. Its almost impossible to know where the exact things we are searching are located in X10 as the Marlin client acts as a platform between the real bootloader/hardware and the user interface (what we see in our X10 from adb/root shells etc).

The real bootloader may very well be present in another chip where the Marlin client cannot have access to read/writes but it can only read that area when it needs to verify the certs and hashes.

Seacert generates the Marlin trust objects (certificates, keys, CRLs, role assertions, etc.)

Sony has only given info about using Marlin in PS3 and PSP but it secretly adopted Marlin in X10 and all the mobiles after X10(Play,Neo,etc)

The only way with which we can really crack this bootloader is by actually reading/writing to the chips which is not at all feasible option or by finding a vulnerability in the Marlin client.

The presence of Marlin DRM can be found by

mtd0 cache

mtd1 appslog

mtd2 userdata

mtd3 system

where boot,recovery partitions are not visible even from root shell. They are hidden from us by Marlin client.

Even in HTC thunderbolt which was recently bootloader cracked have boot/recovery partitions visible from where the original recovery was copied to the sdcard and new recovery image was written from root shell.

No normal known methods can be applied in cracking X10 bootloader.

The only way in is by exploiting vulnerability in Marlin client.

So find marlin client in our X10...find a vulnerability...exploit the vulnerability to find something useful.

zdzihu, jerpelea, wolfbreak and other devs that are building new firmwares upon existing kernel by writing drivers from scratch have all the respect from X10 community, they have done a lot to X10 community without cracked bootloader.

The method that can be applied in cracking bootloader of our X10 will very well work with all upcoming Sony mobiles as they all are using Marlin DRM.
[XPERIA X10 Android Development] tryantar:
i have to totally agree. i mean the easiest way to know is just open build.prop at the last line theres a big fat word Marlin. isnt it proof enough of its existance or am i an oddball here?
[XPERIA X10 Android Development] Bin4ry:
Less discuss more working please :D

I give you something to test.

Please feedback and comment.

Regards

Bin4ry
[XPERIA X10 Android Development] mayank.1love:
Gr8 work Bin4ry

you stopped all the services even the DRM service DxDrmServerIpc and loaded the custom boot.img

Is it complete implementation or does it need some more fine tuning?
[XPERIA X10 Android Development] Bin4ry:
For now Touchscreen seems not to work. Don't know why exactly.

On X8 it can work same way, but you have to create a dedicated image to X8 hardware.

If you don't mind you can create a initlogo.rle (or smd else?) i'm not good in photoshop/gimp :P

I sended Jerpelea the kernel patches (was a patch of goroh too). He uploads it to git, so that everyone can contribute!

Regards
[XPERIA X10 Android Development] Bin4ry:
Bootkit2 inkl. sources

Thanks again to Goroh,Z etc.

inkl. custom bootlogo (thanks Sony_Ericsson_X10)

Package contents:

bootkit -> binary files to run the bootkit

src -> just interesting for people who doesn't need explaination :D

Regards

Bin4ry
[XPERIA X10 Android Development] Bin4ry:
Still trying to start own kernel with kexec right out of running system.

For now, i saw that my kernel bootet the android system but neither Touchscreen or USB is active so i cannot tell you if anything else is working :P

Regards

Bin4ry
[XPERIA X10 Android Development] Blagus:
Is it a permanent solution - once boot.img is loaded and kernel replaced, do we still have to run it every time on reboot, or it stays like it is?
[XPERIA X10 Android Development] krazyd007:
I don't know if this helps any but I stumbled across it this morning.

http://nenolod.net/~nenolod/sholes-keyleak-explained.html
[XPERIA X10 Android Development] mayank.1love:
We still have to load it every time the mobile starts untill we find a solution to write into the bootloader partition or we can also override the init script to start our script automatically at load time.

@Bin4ry

Can you start the script at mobile boot time maybe when the mobile is starting from adb shell before init or from inside init?
[XPERIA X10 Android Development] MrHassell:
+100

This is relevant :) Thanks for this, excellent post! Have to wait until I have more thanks credits as I just spilled them all on Bin4ry for the damn hot files being forked out.. this is killer!

Attached something -bmight be of interest... need to confirm this private key... have a look!

EDIT:

isn't but.. such a funny name ;) - psp?
[XPERIA X10 Android Development] Chillaxed:
Very exciting. Can my bruteforce "project" be useful to crack those smaller keys? Or can we just find them? Does this mean our phones have this same vulnerability?
[XPERIA X10 Android Development] mayank.1love:
Firstly we have to find an exploit to use the bruteforce method . We have to derive some formula based on the exploit so that the keys can be calculated by bruteforcing.

We can check for the same vulnerability but it is probable that this vuln. may not be present in X10.
[XPERIA X10 Android Development] Bin4ry:
Hm,

very interesting. So if Moto and Sony both are too dump to mask their keys, maybe we have a good chance too.

We can try that later, but first somebody has to explain me this function for mathematica:

TL;DR: k = s - sha1sum(data)

whats TL and DR? i know the rest, but mathematica doesn't know any sha1sum function, this is ne smallest problem because sha1sum is very popular.

So is he using a special crypto-package? Who knows more?

Regards

Bin4ry
[XPERIA X10 Android Development] theskeptic:
Too long, didn't read. A euphemism for "I'm lazy".

:p
[XPERIA X10 Android Development] MrHassell:
TL (Tender Loins)

+1 - the_laser is expert in this - OMAP secure bootrom - afik setool is the_laser's project (correct me if I'm mistaken) would be great if this applied to the Xperia - as thankfully pointed out - I really appreciate it ;)

Confirm this with root explorer! look in - /system/build.prop - view as text and scroll to bottom;

ro.drm.active.3=marlin,1

The Elgamal signature scheme was precursor to DSA and variants including Schnorr and Pointcheval-Stern. "Digital signature" is nice reading but my favorite a paperback by Steven Levy called Crypto - great writing could be a movie!