yashsingh1/xdaforums huggingface dataset:
[XPERIA X10 Android Development] goroh_kun:
Hi

I found that we have to patch init_boot_linux function in usbloader source,

named usbloader.c.

this loader used image as in page size 4096, but we have to change

2048.

static int init_boot_linux(void)
{
boot_img_hdr *hdr = (void*) kernel_addr;
unsigned page_mask = 2047;
unsigned kernel_actual;
unsigned ramdisk_actual;
unsigned second_actual;

if((kernel_size < 4096) || memcmp(hdr->magic, BOOT_MAGIC, BOOT_MAGIC_SIZE)){
dprintf("bootimg: bad header\n");
return -1;
}

if(hdr->page_size != 2048 && hdr->page_size != 4096) {
dprintf("bootimg: invalid page size\n");
return -1;
}

kernel_actual = (hdr->kernel_size + page_mask) & (~page_mask);
ramdisk_actual = (hdr->ramdisk_size + page_mask) & (~page_mask);
second_actual = (hdr->second_size + page_mask) & (~page_mask);

if(kernel_size != (kernel_actual + ramdisk_actual + second_actual + 2048)) {
dprintf("bootimg: invalid image size");
return -1;
}

/* XXX process commandline here */
if(hdr->cmdline[0]){
hdr->cmdline[BOOT_ARGS_SIZE - 1] = 0;
memcpy(cmdline, hdr->cmdline, BOOT_ARGS_SIZE);
}
/* XXX how to validate addresses? */
ramdisk_addr = hdr->ramdisk_addr;
ramdisk_size = hdr->ramdisk_size;

kernel_addr = hdr->kernel_addr;
kernel_size = hdr->kernel_size;

cprintf("bootimg: kernel addr=%x size=%x\n",
kernel_addr, kernel_size);
cprintf("bootimg: ramdisk addr=%x size=%x\n",
ramdisk_addr, ramdisk_size);

memcpy((void*) ramdisk_addr,
hdr->magic + 2048 + kernel_actual,
ramdisk_size);

memcpy((void*) kernel_addr,
hdr->magic + 2048,
kernel_size);

return 0;
}

I'm fixing this problem. plase wait a moment :)
[XPERIA X10 Android Development] goroh_kun:
new usbloader

Hi, all

I've uploaded new usbloader for development.

http://hotfile.com/dl/55581651/12cccf5/usbloader_20100716.zip.html

I fixed boot.img recongize problem, and changed, add some functions for

debug till boot.img boots completely. (like in head.S and init/main.c problem.)

from today, I'll try to boot my kernel, and I'll upload patches for kernel.

please wait for next report :)

thanks.
[XPERIA X10 Android Development] andreicloud:
just tell your friend to give us the full code or an idea on how to bypass/write/rewrite it.
[XPERIA X10 Android Development] MrHassell:
Sony Ericsson offers to provide source code

Passphrase for X10 bootloader please! Bootloader for X10 Android series is signed with a 1024bit RSA key and the pass would allow us to open the package, modify the bootloader, resign using certificates / match check-sums adding our own entry / exit points... xRecovery as the standard recovery, multiple boot options.. retaining compatibility with the existing ROM's and future updates.

Naturally this incurs thinking of our own xda boot loader. We are not able to look inside at specific load points - references android/os/IInterface/ and invoke-direct to - android/os/Binder/... etc... we can see a little but not enough to just drop the SE bootloader and implement an xda bootloader.

com.sonyericsson.android.bootinfoif <- interface and methods are here in encrypted and all the pieces to the puzzle lay in the early Donut 1.6 rom. No point in running with >= 2.x builds - most of the mistakes have been fixed in updates and patched so leverage is based on what needed to be fixed, perhaps even a good list of bug track events would be useful but really SE need to live up to their licensing terms when they get involved with "open source" and include the bootloader as part of this source code, the way I see it, this is a violation of their own terms.

"Sony Ericsson offers to provide source code of software licensed under the GPL or LGPL or some other open source code distribution to you on a CD-ROM for a charge covering the cost of performing such distribution, such as the cost of media, shipping and handling, upon written request to Sony Ericsson Mobile Communications AB, Open Source software management, Nya Vattentornet, SE-221 88 Lund, Sweeden. This offer is valid for a period of three (3) years from the date of the distribution of this product by Sony Ericsson"

Settings > About phone > Legal information
[XPERIA X10 Android Development] kordiak:
Try to look at how this data could defeat RSA key http://www.eecs.umich.edu/~valeria/research/publications/DATE10RSA.pdf

I found it on the net, I hope that helps....

Sorry for my English, I use google translator.
[XPERIA X10 Android Development] maxrfon:
You have never heard of FlashGordon2 and certificates :)

There is no private certificates at marlin, all the private certs are with developers, stored localy on their PCs.

I can say that because i know ;)
[XPERIA X10 Android Development] Hawkysoft:
the x509 certificate info here...

first one.....

--------------------------

Subject	1.3.6.1.4.1.23727.1.1.1=#0C2D75726E3A6D61726C696E3A6F7267616E697A6174696F6E3A736561636572743A73656D633A64726D706572736F

Valid From	Oct 13 2009

Valid To	Oct 13 2024

Issuer	1.3.6.1.4.1.23727.1.1.1=#0C2675726E3A6D61726C696E3A6F7267616E697A6174696F6E3A736561636572743A64726D737663

Signature Algorithm	sha256WithRSAEncryption

Serial Number	59:2f:94:63:0b:2e:85:bf

second one.....

---------------------------

Subject	1.3.6.1.4.1.23727.1.1.1=#0C2675726E3A6D61726C696E3A6F7267616E697A6174696F6E3A736561636572743A64726D737663

Valid From	Feb 2 2008

Valid To	Feb 2 2028

Issuer	1.3.6.1.4.1.23727.1.1.1=#0C1675726E3A6D61726C696E3A64726D7365727669636573

Signature Algorithm	sha1WithRSAEncryption

Serial Number	78:cd:b0:24:be:90:72:1c

ok i whus kinda doing some stuff.. and found out this word... since it makes total no sence to be there.. can someone try it?

magic word i found whus...

191a4f8c110155e8d1cce191401e0fe9606ae371 : sony17
[XPERIA X10 Android Development] enition:
Please delete if this is no help but..

$ openssl x509 -noout -modulus -in s1_loader_root.cer | openssl md5

and

$ openssl rsa -noout -modulus -in test.key | openssl md5

Both match: d41d8cd98f00b204e9800998ecf8427e

Does this not mean that this key is correct?
[XPERIA X10 Android Development] MrHassell:
Maxfron the Marlin method uses the Octopus DRM at the bootstrap. Forget about keyz, they are useless. There maybe a flaw in the older basebands which allowed for an exploit on fingerprint matching to loader.sin and hence the SE updated baseband. Passphrases, keys etc are actually in your phone. EDIT: - The certificates are revoked easily on boot, they must match what is inside the EPROM.

The EPROM is not an EEPROM. It can never be modified and this inititates the bootstrap, protected by Marlin. This will never be broken, ever (absurd time wasting, when so many easier things exist). Want a hacked bootloader, buy a HTC because this is tighter than any other phone in existence, a poster child for the Octopus / Marlin DRM. Didn't deter me from buying the phone, I love a challenge but common sense should dictate at this point. It will never happen, there is no way of hacking it and the only option is to either get another phone OR live with it and work around it and create a bootloader that matches fingerprints and fakes it well enough to allow for the required mods.

EDIT: validation - isolate drm into it's own box - kexec as module and wipe

Sockeye'Hardened'Cryptography'Solution:'A'Technical'Overview​

Overview

Intertrust’s Sushi Marlin Client SDK is a mature, highly portable commercial implementation of the Marlin Broadband DRM system that has been ported to a broad spectrum of System on a Chip (SoC) based devices.

... provides a minimal programmatic abstraction layer or Application Programming Interface (API) that confines the handling of secrets (primarily cryptographic keys) to a small and verifiable code module. Depending on the system architecture, this code module may directly interact with a security processor integrated on the SoC. With this level of integration, cryptographic keys and other secrets can be isolated from applications running on the general purpose CPU and always be shrouded by the security processor. Ideally, cryptographic keys are only in the clear within the protected memory space of the security processor, and all encryption, decryption, signing, and verification functions are executed on the security processor.

http://www.intertrust.com/system/files/20100913%20-%20Sockeye-Technical%20WP%20-%20v1.1.pdf
[XPERIA X10 Android Development] MrHassell:
1 option - kexec

can't be patched due to the drm, crypto - so do I just compile kexec and launch from su?
[XPERIA X10 Android Development] zdzihu:
I prepared a kexec pack for a quick start. It includes:

- splboot.ko for 2.1 (latest kernel .435)

- miniloader

- sample boot image

- instructions etc

Currently I am getting panic on q6audio init / kgsl - messing around to patch it.

Calling all kernel hackers out there - we need your help!

http://www.mediafire.com/?wuo2qjat02a5l61

Cheers,

z
[XPERIA X10 Android Development] maxrfon:
First of all disable MPU, then do your job. It works, i bet.

I did it with radio reset but then i found a better way of doing this(by the above written).
[XPERIA X10 Android Development] maxrfon:
this makes no sence :) then all you need to do is to create your own certificate, replace it and sign with your private key :) LOL, that would be funny if it was so.

But it's not. The pass/key is inside the bootrom, that's it.

No matter how it's called it still a key.
[XPERIA X10 Android Development] zdzihu:
Hi Max,

Thanks for the answer. So far I've tried to reset mcpu but without any success (reset = hard reboot). I'm going to gather some more info about it and give it a go.

If I only knew what MPU was and how to disable it :)

If you have any clues how to achieve the target, please drop me a PM/mail.

Cheers,

z
[XPERIA X10 Android Development] MrHassell:
this post > /dev/null - mpu - all memory is protected.. is it just me but when you go past load the mounts appears isolated - appears virtual, like the fw isnt running on the metal but in protected memory on init from this usbloader thing?
[XPERIA X10 Android Development] Hawkysoft:
mpu shud be one of these i think.... other options are out of the case

micro processing unit

memory protection unit

unless its MPU-401 than you should look here but this is the sound driver... unless ur lookin on the wrong spot u need this i think o.0

maybe this is interesting also for you...

4e93059935d9869d41d28889052e8d6d64fd77cf Revert "Disable MPU WDT"
d94553ac32a2e723030dcb4c7e93342ada336631 Disable MPU WDT

and this o.0

// removing modem memory protection
pa=ioremap(0xA8240000, 4096);
printk("Reseting 0xA8240800 (%X) MPU\n", pa);
if (!pa) {
printk("unable to realloc 0xA824000");
return -EBUSY;

and maybe you should read this
[XPERIA X10 Android Development] MrHassell:
likewise if I've offended in anyway my apologies, must be too tired and writing things off key - my bad...

your post with key and the sony17... where did you find it, how did you extract it from the device? IF the correct key, how can I verify it's validity?

You can validate it with open ssh but how can you implement it? very interesting!

The 'master key' as I see se have called it, is embedded in the eprom - from there some little code block is called in the next stage to validate and then uses the nemo web services to get certificate revocation list.. it's empty to date ;)

let's see now if we can do something about that, after all what good is a system left untested? I'm looking at step 3... from z and thinking - module
[XPERIA X10 Android Development] Hawkysoft:
erhm how i got the sony17 hmm... cant tell you sorry... just hope it works

im still learning allot and searchin as much as info i can gather to help around...

but since im in the middle of stuff i cant do to much

p.s. dun worry bro, im not offended that fast ;) we're all trying to help like i said in pm
[XPERIA X10 Android Development] Hawkysoft:
Oh and the signature values where given encrypted, just decrypted that ;) easy as pie
[XPERIA X10 Android Development] maxrfon:
My friend, i actually do not care of what who says, but i can say once:

All certificates are stored at the master FLashGordon2 suite facility.

I have no rights to disclose anything and i won't but i can just tell you that i have it, except the newest S1 here, at my own PC (which is ofcourse, not connected to internet and local network). I have S1 brown, to sign brown firmwares and locaders, but it won't help as it wont work on RED phones. So please stop this senseless argue with me :)

I agree, SE and other manuffacturers that use DRM to sign firmwares, are arrogantly violating our rights, but nothing you can do but sue them :)

So i think that's enough for now and let's continue working.

Here, just for you to see:

####################################################

# SEMC DEVELOPER DB3150 CID52-49,0 Certificate

@_START_CERT

EMP_HEADER_SIZE:4;

SEMC_CERTIFICATE_SIZE:0;

PK_N_SIZE:0;

PK_D_SIZE:0;

PK_E_SIZE:0;

HEADER_TAG:BROWNBLUE_CID52-49-0_DB3150;

CID_TAG:CID52;

PLATFORM_TAG:DB3150;

CERTIFICATE_STRING:Certificate Version BROWNBLUE_CID52-49-0_DB3150;

HEADER_DATA:ba,be,02,00;

CHIPCLASS_DATA:00,02,00,00;

CERTIFICATE_DATA:
[XPERIA X10 Android Development] Blagus:
So, can you confirm once for forever what I was saying (or disagree with me) - if you had red certificate, could you sign modified S1Boot image and flash it?

And second question, would idea of custom certificate signed with root certificate work? (in case that even idea of signing with red key is true)
[XPERIA X10 Android Development] Hawkysoft:
i whus surfing on the web and walked against this, now has this any use for what we need or just some random outdated flasher for old phones?

here's the latest version of it
[XPERIA X10 Android Development] aZuZu:
If SETool3 doesn't unlock or flash S1 platform nobody does..
[XPERIA X10 Android Development] MrHassell:
Maxfron im not wanting to argue or disagree. Your concept is sound and makes perfect sense. In brownblue or engineering keys, can sign then release a firmware with these. Zdzihu already release a rom with test keys on the fingerprint, so this holds true.

The SEUS bootstrap DRM thing has obviously really upset me. It's not anyone here that I have any issue with, how is my frustration can we work past marlin?

sent from heaven via x10a custom
[XPERIA X10 Android Development] Hawkysoft:
Its capable to change phones color if u readed the posts before u would know
[XPERIA X10 Android Development] tryantar:
Right i may not be a dev but after i read MrHassell's post i did some research and came up with this:

http://www.intertrust.com/system/files/Octopus_Specifications_v.1.0.3.pdf

not sure if its of any use.. Maybe you guys have already found it.. or not...

Its the specifications for the octopus thingy MrHassell wrote about in the Marlin project and stuff... really confusing >< I hope the great minds here could make sense of it =)

It may be of no great use at all for us to crack the boot loader since its posted on the net and i kinda got it off easily... but im having some hope that it does. =)
[XPERIA X10 Android Development] MrHassell:
How to decrypt

http://pastie.org/1419148

replace with the right codes and your good. (if it's a PS3 that is - LOL) - but this is nothing like a PS3 - I know..
[XPERIA X10 Android Development] MrHassell:
choco starfish

um.. mate? maaaate... ma.. haha... wha? where do I sign?
[XPERIA X10 Android Development] maxrfon:
I have option to load img file and sign it against my certificates.

When the phone is brown it just works :) When the phone is RED it gives me an error.

IMG files are signed as img files and the update.zip file is signed separately, there is an option for it too.

So being very short- all we need is one record:

####################################################

# Autogenerated key file

#

# Generation Tool: SEMC cert_data_generator

# Version 00.00.01

#

# Sony Ericsson Moblie Communications AB

# Strictly Confidential content

#

####################################################

# __

@_START_CERT

SEMC_CERTIFICATE_SIZE:442;

PK_N_SIZE:129;

PK_D_SIZE:129;

PK_E_SIZE:3;

HEADER_TAG:S1_CUST_RED;

CID_TAG:;

PLATFORM_TAG:QSD7227_SW; bla bla for 72xx

PAYLOAD_TYPE:CUSTOM;

CERTIFICATE_STRING:S1_Cust_RED_a230_01; bla bla bla

HEADER_DATA: xxxxxxxxx ;

CERTIFICATE_DATA: xxxxxxxxxx ;

PK_N_DATA: xxxxxx;

PK_D_DATA: xxxxxx;

PK_E_DATA: xxxxxx;

@_END_CERT

Sing system.img with the aign tool, get the system.sin out and be happy with custom OS.
[XPERIA X10 Android Development] maxrfon:
Hey Z, did you check your PM?

Can you please feedback?

M
[XPERIA X10 Android Development] Blagus:
Exactly what I was saying, but then MrHassel and HTC Desire guy came and told me that's not possible... But I am very sure that if you had S1_Loader (Red) certificate you could sign modified loader.img and flash it to phone without any problems as long as there are present some hashes or however someone called it, what is required for DRM (if that's true at all :confused:)

I don't know who should I listen to anymore... You're the one who I want to trust, and I'd like that you could flash your own image to phone (or give us some signed file for flashing) to prove idea of Octopuses and DRMs wrong ;) To prove that all we need is S1 Loader Red certificate to flash custom "bootloader"
[XPERIA X10 Android Development] RaDi:
i know Don Po (my freind freind) he know how to flash Brown and red SW to SE phones , i will seeif he can help us .....
[XPERIA X10 Android Development] Blagus:
You mean den_po?? AFAIK he works on A1 and A2 platforms, not S1... But the_laser maybe knows something...
[XPERIA X10 Android Development] :
Greetings.

long time i watched that thread, but due to recent posts decide to register, post 10 messages and write something ;)

so, lets summary s1 security implementation on qualcomm platforms:

1. semcboot protected by qualcomm signature ( "SEMCSEC QSD8x50 Attestation Cert")

semcboot checked by qualcomm bootrom, that rendering ideas like "we will rewrite own bootloader and own semc" useless

2. semcboot checking amss ( no simlock patch, maxrfon ;) ) , dsp,fota,fota1,kernel "converted-elf" images against semc signatures

3. each firmware part protected by own key -

S1_SL protecting simlock signature

S1_SW protecting firmware code parts

S1_Loader protecting external loaders

S1_Cust not used in androids

S1_HWConf protecting security block (imei, debug flag, security flag)

4.

each S1 platform has own keys - e10,e15,u20 has one keyset, x10 another, etc.

x10, for example, has ac12 keyset, e10-like has 3edc keyset and so on.

5.

to enable unsigned images (images, signed with test keys, available to anyone intrested ) upload we need pass S.A.K.E auth in loaders, basically it has next steps (simplified):

- phone generating random challenge, contacts it with imei and send to host

- host send data to secs server, secs server encrypts it with S1_SAKE private key (again, each key different for each s1 platform), rsa key len 2048 bit

- host send received data to phone

- phone verify received data against public key in loader, then decrypt signature and verify imei+random+auth level against initially generated.

6. to enable running signed by test keys on retail phones, one need to generate hwConfig with security flag set to 0.

that require... right, s1_hwconf_root or "at least" ;) s1_hw private key

7. summary:

- it is only possible to "crack" semboot after 6-7 years (pc power should be enough that time to break rsa 1024 key)

- there is no known weakness in semcboot security algorithms

- to use patched firmware, one need s1_sw (or s1_sw_root ) private key or s1_hwconf (s1_hwconf root )

ergo:

s1 security unbreakable at the moment without

- access to mentioned private keys

- access to development secs server, which able to generate hwconfigs

[offtopic on]

@blagus:

how aunt lead'a feels ? is all okay with her ? i hear, she again changed name, now she is "seraph" ? ;)

send greetings from the_laser ;) of course, send my usual "f...k" to mizer.

@ahmed_radi:

don_po ;) will not help you. he is, like other russian semc reversers, very experienced... in researching others stuff.

however, here is no stuff to research ;)

[/offtopic on]
[XPERIA X10 Android Development] Blagus:
Nice, the_laser finally here ;)

So you're saying that there is no any known flaws in S1 phones at all right now?

Is that the reason why I never heard of "non-EMMA" S1 unlock method?

SE really did excellent job on protecting their phone this time... unlike "good old" DB2020 modding - by the way, I think we should thank to you for DB2020 CID52 alternative bypass...

But what about loading zImage via kexec? Is that monitored by EROM too?
[XPERIA X10 Android Development] Hawkysoft:
everytime someone state a specific time to crack the bootloader i laugh harder than u can imagine... cuz the maximal duration u are calculating if the key is the last key... who ever says its not the first? or thousands? i can tell you one thing the key of sony ericsson isnt that long, unless they became physcophrenic lol

if you can make the program to crack the bootloader please do.... and i'll run it on dozens of computers.
[XPERIA X10 Android Development] Bin4ry:
Hey laser,

nice to hear from you here @ XDA. And thanks again for the hint with my flashtool.

Thanks for the very good explainations. So the SE-security goes a little deeper than i thought before ;)

After your post i finally know that the only hope for this phone is a kexec attempt. But as you see we still have the same old problems with kexec.

Can you give us a hint for this too ? ^^

OR do you have any other ideas you want to spread in this developer thread?

Best Regards

Bin4ry

P.S.:

Flashtool does not rewrite the partition table anymore. I fixed this fault after you told me about. Thanks again for this =)
[XPERIA X10 Android Development] :
@blagus:

starting from very first s1 phone (if memory serves, that was z320 or maybe t250 ?) there was no known ( public ) bugs in security.

i did not heard about private bugs too.

about zImage via kexec i can say only one thing - semcboot do not cares about firmware after it verified and started.

however, i should add, that semcboot builds and keep in memory parameter passing area with security functions for firmware.

it is used,mainly for simlock verification,drm etc.

@binary:

if you explain to me that problem, perhaps, i can help with checking in

M76XXTSNCJOLYM53404015.elf-like files.

i'm not good with all that internal *nix kernel things, but i can learn ;)

ps.

why you quys quote my entire message ?

ehehe, in good old FIDO times you were put in read-only mode at least for a week ;)
[XPERIA X10 Android Development] Bin4ry:
Hey my friend,

Have you found more qcom since our last speak? I haven't found any interesting, but maybe i'm seeking on the wrong places.

BTW, have you noticed that the phone acts weird in some cases if you resend another loader after you "flashed" the right loader?

More explaination:

I send the original loader.sin to phone -> phone accepts blablabalba -> immediatly i send another loader -> phone shows up with another pid in some cases, but it's just for a few seconds then its away again.

I think it's some timing problem here, but atleast i got the phone confused maybe it overwrites the previous send loader right after checking it's signature and trys to execute the file at his memory address, but "hello" there is my faulty loader and because it cannot execute it -> it switches to another mode.

Maybe i should investigate a little more here, but maybe it's just nothing ^^

Regarding to Z: He is not answering my pm aswell. Don't know if he is too busy or smth. else.

@the_laser:

Look a few pages back, you will see the main problem with kexec.

Here is the latest pack that was created by Z this time:

http://xdaforums.com/showpost.php?p=11258584&postcount=590

a few pages before i tryed some thing to kexec tool but haven't worked too.

I think that the MPU needs a reset for our attempt. But if i tryed to reset mpu the whole phone resets -> Bad :/

Regards

Bin4ry