Database Users

help for SIM Acces

Hi all,
I am new to this forum and happy to be part of it. I am facing one problem. Hope you all can take a look at this.
I have an EAP-SIM application which needs to be ported to Windows CE Pocket PC 2003. It will probably run on HP iPAQ. I need to get the IMSI of the SIM card and run the GSM (A3/A5/A8) algorithms through my application.
After a lot of research, i found it might be possible through AT commands and with the help of RIL(Radio Interface Layer). I tried some samples, but is not working properly. I saw some AT commands in this link
http://ftp.rz.tu-bs.de/pub/mirror/cc..._log_commented
Next I tried this with RIL.
I need to know how i can get IMSI and send some PDU to the SIM card to run the algorithm. Is it possible ? through RIL ? AT command ? . Your valuable help or suggestion is expected.
-------------------------------------------------------------------
const BYTE SELECT_FILE_CMD[] = {(BYTE)0xA0, (BYTE)0xA4, (BYTE)0x00, (BYTE)0x00, (BYTE)0x02,(BYTE)0x3F,(BYTE)0x00};
const BYTE GSM_DIR_CMD[] = {(BYTE)0xA0, (BYTE)0xA4, (BYTE)0x00, (BYTE)0x00, (BYTE)0x02,(BYTE)0x7F,(BYTE)0x20};
const BYTE SELECT_EF_IMSI_CMD[] = {(BYTE)0xA0, (BYTE)0xA4, (BYTE)0x00, (BYTE)0x00, (BYTE)0x02,(BYTE)0x6F,(BYTE)0x07};
const BYTE GET_IMSI_CMD[] = {(BYTE)0xA0,(BYTE)0xB0,(BYTE)0x00,(BYTE)0x00, (BYTE)0x09 };
const BYTE READ_IMSI_CMD[] = {(BYTE)0xA0,(BYTE)0xC0,(BYTE)0x00,(BYTE)0x00, (BYTE)0x09 };
result = RIL_Initialize(1, ResultCallback, NotifyCallback, dwNotificationClasses, g_dwParam, &g_hRil);
res_UserIdentity = RIL_GetUserIdentity(g_hRil);
//res_SelectFile = RIL_SendSimCmd(g_hRil, SELECT_FILE_CMD,sizeof(SELECT_FILE_CMD));
//res_Select_IMSI = RIL_SendSimCmd(g_hRil, SELECT_EF_IMSI_CMD,sizeof(SELECT_EF_IMSI_CMD));
//res_Get_IMSI = RIL_SendSimCmd(g_hRil, GET_IMSI_CMD,sizeof(GET_IMSI_CMD));
//res_Read_IMSI = RIL_SendSimCmd(g_hRil, READ_IMSI_CMD,sizeof(READ_IMSI_CMD));
-------------------------------------------------------
Thanks,

Hi, could you repost the link you added, its not working when I click on it.
The commands to select the IMSI seem correct, you have the address right, although I think you might have the last 2 in the wrong order. The 0xb0 command is read binary, and 0xc0 is get response. Typically you would select 3f00, 7f20, 6f07, then send the response command with the length as the final byte (given as the second returned byte from the previous command). You then use the read binary command with the length as the final byte.
Having said that, as you already know the length, you could skip the response command altogether.
here is the trace from my PC based program im developing when selecting the IMSI:
A0 A4 00 00 02 3F 00
A0 A4 00 00 02 7F 20
A0 A4 00 00 02 6F 07
9F 0F
A0 C0 00 00 0F
90 00 00 00 00 09 6F 07 04 00 1D 00 1D 01 02 00 00
A0 B0 00 00 09
IMSI: 90 00 ......

Hi,
Thanks for your reply. Please find the link below
http://ftp.rz.tu-bs.de/pub/mirror/ccc_Chaos_Computer_Club/ftp.ccc.de/gsm/gsm_log_commented
The real problem is am using RIL. In RIL_SenSimCmd ( ), the error code i got is
80004001 which means its not implemented. I am using HP iPAQ. Does this execution of AT commands depends upon the mobile phone ? As you mentioned about your PC program,Are you using smart card reader or something else ? Can you please tell me how you did it ?
Right now am just trying to send a single AT command to select the GSM file after RIL initialization. That itself is failing.
const BYTE GSM_DIR_CMD[] = {(BYTE)0xA0, (BYTE)0xA4, (BYTE)0x00, (BYTE)0x00, (BYTE)0x02 ,(BYTE)0x7F,(BYTE)0x20};
result = RIL_Initialize(1, ResultCallback, NotifyCallback, dwNotificationClasses, g_dwParam, &g_hRil);
if (result < 0)
{
wsprintf(szString,L"RIL_Init-%d",result);
ShowMessage(szString);
}
res_GSMDir = RIL_SendSimCmd(g_hRil, GSM_DIR_CMD,sizeof(GSM_DIR_CMD));
if (res_GSMDir < 0)
{
wsprintf(szString,L"res_GSMDir %x",res_GSMDir);
ShowMessage(szString);
print_error(-1 * res_GSMDir);
}
So I assume my iPAQ is not allowing me to execute commands ?. Please give a brief about this. Please let me know if you didnt get the link. I wil send it to your mail id..
Thanks,

My knowledge with AT commands and RIL is limited im afraid, but I'd guess ipaq's dont use the standard AT commands. The error being returned would suggest to me that the command is incorrect and not recognised, so you're probably sending it in the wrong format.
All I can do is point you to a few links you probably have already looked at, namely microsofts msdn article on RIL application
http://msdn2.microsoft.com/en-us/library/ms894929.aspx
and handhelds site, which may contain useful info on your device that could help in development.
http://handhelds.org/
As for my program, im writting it in VC++ using the scard platform. And yes, im using a card reader.
The command structure is:
CCardServer::SCardCommand(LPCSTR Cmd, LPSTR DataIn, INT DataInLen, LPSTR DataOut, INT DataOutLen)

Hi sanal,
sanal said:
... I have an EAP-SIM application which needs to be ported to Windows CE Pocket PC 2003.
Click to expand...
Click to collapse
EAP-SIM --> i wish you good luck
sanal said:
... I need to get the IMSI of the SIM card and run the GSM (A3/A5/A8) algorithms through my application.
After a lot of research, i found it might be possible through AT commands and with the help of RIL(Radio Interface Layer). I tried some samples, but is not working properly. I saw some AT commands in this link
Click to expand...
Click to collapse
why not using SIM Manager? see SIM Manager Reference at MSDN.
This API is available for PocketPC 2002 and later..
Here a codesnippet out of SIMSpider, which i've written some time ago..
(if SIM Manager fails, then it's probably not implemented by hp for your device..)
Code:
// dwAddress:
// 0x6F07: IMSI
// 0x6F20: KC Ciphering Key
void ReadSIM ( DWORD dwAddress )
{
HSIM hSim;
HRESULT hr = SimInitialize ( 0, NULL, NULL, &hSim );
if ( hr == S_OK )
{
SIMRECORDINFO sri;
memset ( &sri, 0, sizeof(sri) );
sri.cbSize = sizeof(sri);
hr = SimGetRecordInfo ( hSim, dwAddress, &sri );
if ( hr == S_OK )
{
DWORD dwBytesRead;
BYTE pBuf [ 4096 ];
hr = SimReadRecord ( hSim, dwAddress, sri.dwRecordType, NULL, (LPBYTE)pBuf, sizeof(pBuf), &dwBytesRead );
if ( hr == S_OK )
{
// here you can decode the data according to gsm-spec
// e.g. http://www.ttfn.net/techno/smartcards/gsm11-11.pdf
}
else
wprintf ( L"Failed to read Record!" );
}
hr = SimDeinitialize ( hSim );
}
else
wprintf ( L"SimInitialize failed with %08X", hr );
}
for EAP-SIM you may need the ciphering key too.. don't know for sure..
for decoding the sim-files you can find any needed info e.g. in http://www.ttfn.net/techno/smartcards/gsm11-11.pdf
and so on...
hope it helps
Cheers,
ikarus

Hi ikarus,
Thanks a lot for your reply. I am reached half way. Got IMSI and Kc with SIM Manager. What to do with the Run GSM Algorithms. I think for that we need to send some commands to SIM. I have no hope of doing algorithms execution through SIM manager. Any idea ?

Hello sanal,
you're right. With SIM Manager there seems to be no way for running gsm algorithms.
Furthermore i'm not sure if you really need the imsi and kc.
As far as i know for eap-sim you send the algorithm (sim) a random, which the nas (respectively the authentication-entity behind) sends to you.
I'm not very well experienced with this, so you're on your own.
hm.. you could have a look at RIL_SendRestrictedSimCmd, but there is no constant for "Run GSM Algorithm".
You could also try RIL_SendSimCmd and format the command according to gsm-specs. In the mentioned document there is a chapter 9 - Description of the commands ..
(but i guess an official gsm-spec would be more helpful)
Maybe another user can help more?
good luck !
ikarus

yes I think needs to do more research. Particularly whether iPAQ supports this AT commands. Bcoz as of i know phones restrict this command AT+CSIM. As you mentioned i have already checked the specs ,
as limbmaster said i need to check whether am sending the commands correct or wrong. But my doubt is when i try AT+CSIM through serial com, it says error. then This is bcoz phone is not allowing you. Then how RIL will work.. Anyway need to look how GSM algorithm can be done.

Locking/Unlocking device

Hi All
I am searching for a way to lock/unlock the device. I had found several undocumented functions in aygshell.dll (please note, that I could reveal only function names and numbers, and parameters were found practically, but this information is not verified and probably is not correct).
Code:
/*
Used to lock/unlock the phone
0 - E_FAIL
1 - Unlocks the device, but do not update plugin icon on Today screen and do not closes Unlock.
When user press Unlock - it does not ask to press unlock button and unlocks the device
2 - Locks the device, changes lock plugin icon on Today screen
3 - same as 1
4 - if device is locked, there is no way to unlock it (though Unlock button can be pressed,
no unlock screen is available),
if device is unlocked, icon changed to locked but device is still unlocked and lock plugin hangs
5 - same as 4
6 - Locks the device with no posibility to unlock
7 - same as 6
8 - E_FAIL
9 - if unlocked then as 4, if locked as 1
*/
HRESULT SHLock(DWORD dwCommand); // function #121
/* Shows Unlock dialog
0 - unknown
1 - sometimes ask to press Unlock, sometimes - press Cancel
else - ask to press cancell then unlock
*/
HRESULT SHUnlock(DWORD dwParam); // function #122
/* Returns in pdwState current lock state
0 - Unlocked
2 - Locked
*/
HRESULT SHIsLocked(LPDWORD pdwState); // function #123
/* I think it writes the lock state, probably has more parameters
dwParam should be greater then 1;
current state is written to dwOldState
*/
HRESULT SHWriteLockState(DWORD dwNewState, LPDWORD dwOldState); // function #124
/* I don't know how does this work
It should be called after SHWriteLockState.
when dwParam = 2 it unlocks the phone
*/
HRESULT SHClearLockState(DWORD dwParam); // function #125
To unlock the device I call ShLock(1) and then send the emulate pressing menu button Unlock (I do not provide error handling for simplicity):
Code:
HRESULT hr;
HWND hWnd;
hr = SHLock(1);
hWnd = ::GetParent(::GetParent(WindowFromPoint(pt)));
hr = ::PostMessage(hWnd, WM_COMMAND, 0x409, (LPARAM) hWnd);
This code works well on my emulator, however it doesn't work on a customer's HTC pocketpc and I have no possibility to check this on real device.
However standard Phone application does not send that message to unlock window, so I think there are other set of parameters to some functions.
Please help me to find out how to deal with that functions, or how to unlock the phone in other way.
To make it easier I will provide a declaration code below.
Code:
#define LOCKSTATE_UNLOCKED 0
#define LOCKSTATE_LOCKED 2
HRESULT (*SHLock)(DWORD dwValue);
HRESULT (*SHUnlock)(DWORD dwValue);
HRESULT (*SHIsLocked)(LPDWORD pStatus);
HRESULT (*SHWriteLockState)(DWORD dwParam, LPDWORD pPreviousState);
HRESULT (*SHClearLockState)(DWORD pState);
...
HMODULE hLib = LoadLibrary(L"aygshell.dll");
*(FARPROC*) &SHLock = GetProcAddress(hLib, (LPCWSTR) 121);
*(FARPROC*) &SHUnlock = GetProcAddress(hLib, (LPCWSTR) 122);
*(FARPROC*) &SHIsLocked = GetProcAddress(hLib, (LPCWSTR) 123);
*(FARPROC*) &SHWriteLockState = GetProcAddress(hLib, (LPCWSTR) 124);
*(FARPROC*) &SHClearLockState = GetProcAddress(hLib, (LPCWSTR) 125);
...

[GUIDE] Color correction. Loadable mDNIe color profiles.

I hope I've brought something useful here.
I figured out how to load mDNIe color profiles from sdcard.
So this I found out so far:
1. you have to be rooted;
2. profiles MUST be placed in /sdcard/mdnie folder;
3. profile is a text file and can be edited with any text editor;
4. file name is irrelevant ;
5. you have to edit two titles inside profile file to correspond to profile, you're going to override, eg. you're using AMOLED cinema mode. It's internal name is DYNAMIC_UI, so titles inside profile should be DYNAMIC_UI_1 for longer array and DYNAMIC_UI_2 for shorter one.
The whole list of model with corresponding internal names:
AMOLED cinema mode - DYNAMIC_UI;
AMOLED photo - STANDARD_UI;
Basic - NATURAL_UI;
6. first lines (bytes) of arrays are special marks (0xEC and 0xEB) and should not be touched;
7. to enable profile you have to write into /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning:
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning
8. PROFILE WILL RESET AFTER SCREEN OFF/ON CYCLE. For now I'm using Tasker to refresh it on screen on event. Maybe later we'll figure out some more elegant way;
UPDATE:
Written a small app for PC to tune colors through ADB. Useful for displaying some fullscreen test picture on device and drag sliders on PC to see effect (if any).
Profile structure description is in 2nd post.
That's it by now. There are comments from kernel source, but not too much descriptive (attached here).
I'd extracted and formated properly some major profiles. Attaching them here. Now we need to play allot with them to find out what each byte is doing exactly.
All profiles attached here have matching line numbers. I suggest to keep this pattern, so it will allow us to refer particular byte by line number while discussing here.

Profile bytes with description:
Description will be updated as figured out.
Code:
1 : BYPASS_2
2 : {
3 : 0xEB,
4 : 0x01, /* mdnie_en */
5 : 0x00, /* data_width mask 00 0000 */
6 : 0x00, /* ascr_roi 1 ascr 00 1 0 */ (only odd values 1-155, affects lines 132-155)
7 : 0x02, /* algo_roi 1 algo lce_roi 1 lce 00 1 0 00 1 0 */
8 : 0x00, /* roi_ctrl 00 */
9 : 0x00, /* roi0_x_start 12 */
10 : 0x00,
11 : 0x00, /* roi0_x_end */
12 : 0x00,
13 : 0x00, /* roi0_y_start */
14 : 0x00,
15 : 0x00, /* roi0_y_end */
16 : 0x00,
17 : 0x00, /* roi1_x_strat */
18 : 0x00,
19 : 0x00, /* roi1_x_end */
20 : 0x00,
21 : 0x00, /* roi1_y_start */
22 : 0x00,
23 : 0x00, /* roi1_y_end */
24 : 0x00,
25 : };
26 : BYPASS_1
27 : {
28 : 0xEC,
29 : 0x18, /* lce_on 0 lce_gain 0 0 00 0000 */
30 : 0x24, /* lce_color_gain 00 0000 */
31 : 0x10, /* lce_scene_change_on scene_trans 0 0000 */
32 : 0x14, /* lce_min_diff */
33 : 0xb3, /* lce_illum_gain */
34 : 0x01, /* lce_ref_offset 9 */
35 : 0x0e,
36 : 0x01, /* lce_ref_gain 9 */
37 : 0x00,
38 : 0x66, /* lce_block_size h v 0000 0000 */
39 : 0xfa, /* lce_bright_th */
40 : 0x2d, /* lce_bin_size_ratio */
41 : 0x03, /* lce_dark_th 000 */
42 : 0x96, /* lce_min_ref_offset */
43 : 0x00, /* nr sharp cs gamma 0000 */ (unsharpen mask radius (0-15))
44 : 0xff, /* nr_mask_th */ (unsharpen mask threshold)
45 : 0x00, /* sharpen_weight 10 */ (unsharpen mask strength (0-199))
46 : 0x00,
47 : 0x07, /* sharpen_maxplus 11 */
48 : 0xff,
49 : 0x07, /* sharpen_maxminus 11 */
50 : 0xff,
51 : 0x01, /* cs_gain 10 */
52 : 0x00,
53 : 0x00, /* curve_1_b */
54 : 0x20, /* curve_1_a */
55 : 0x00, /* curve_2_b */
56 : 0x20, /* curve_2_a */
57 : 0x00, /* curve_3_b */
58 : 0x20, /* curve_3_a */
59 : 0x00, /* curve_4_b */
60 : 0x20, /* curve_4_a */
61 : 0x00, /* curve_5_b */
62 : 0x20, /* curve_5_a */
63 : 0x00, /* curve_6_b */
64 : 0x20, /* curve_6_a */
65 : 0x00, /* curve_7_b */
66 : 0x20, /* curve_7_a */
67 : 0x00, /* curve_8_b */
68 : 0x20, /* curve_8_a */
69 : 0x00, /* curve_9_b */
70 : 0x20, /* curve_9_a */
71 : 0x00, /* curve10_b */
72 : 0x20, /* curve10_a */
73 : 0x00, /* curve11_b */
74 : 0x20, /* curve11_a */
75 : 0x00, /* curve12_b */
76 : 0x20, /* curve12_a */
77 : 0x00, /* curve13_b */
78 : 0x20, /* curve13_a */
79 : 0x00, /* curve14_b */
80 : 0x20, /* curve14_a */
81 : 0x00, /* curve15_b */
82 : 0x20, /* curve15_a */
83 : 0x00, /* curve16_b */
84 : 0x20, /* curve16_a */
85 : 0x00, /* curve17_b */
86 : 0x20, /* curve17_a */
87 : 0x00, /* curve18_b */
88 : 0x20, /* curve18_a */
89 : 0x00, /* curve19_b */
90 : 0x20, /* curve19_a */
91 : 0x00, /* curve20_b */
92 : 0x20, /* curve20_a */
93 : 0x00, /* curve21_b */
94 : 0x20, /* curve21_a */
95 : 0x00, /* curve22_b */
96 : 0x20, /* curve22_a */
97 : 0x00, /* curve23_b */
98 : 0x20, /* curve23_a */
99 : 0x00, /* curve24_b */
100 : 0xff, /* curve24_a */
101 : 0x20, /* ascr_skin_on strength 0 00000 */
102 : 0x67, /* ascr_skin_cb */
103 : 0xa9, /* ascr_skin_cr */
104 : 0x0c, /* ascr_dist_up */
105 : 0x0c, /* ascr_dist_down */
106 : 0x0c, /* ascr_dist_right */
107 : 0x0c, /* ascr_dist_left */
108 : 0x00, /* ascr_div_up 20 */
109 : 0xaa,
110 : 0xab,
111 : 0x00, /* ascr_div_down */
112 : 0xaa,
113 : 0xab,
114 : 0x00, /* ascr_div_right */
115 : 0xaa,
116 : 0xab,
117 : 0x00, /* ascr_div_left */
118 : 0xaa,
119 : 0xab,
120 : 0xff, /* ascr_skin_Rr */
121 : 0x00, /* ascr_skin_Rg */
122 : 0x00, /* ascr_skin_Rb */
123 : 0xff, /* ascr_skin_Yr */
124 : 0xff, /* ascr_skin_Yg */
125 : 0x00, /* ascr_skin_Yb */
126 : 0xff, /* ascr_skin_Mr */
127 : 0x00, /* ascr_skin_Mg */
128 : 0xff, /* ascr_skin_Mb */
129 : 0xff, /* ascr_skin_Wr */
130 : 0xff, /* ascr_skin_Wg */
131 : 0xff, /* ascr_skin_Wb */
132 : 0x00, /* ascr_Cr */ red in cyan
133 : 0xff, /* ascr_Rr */ red in red
134 : 0xff, /* ascr_Cg */ green in cyan
135 : 0x00, /* ascr_Rg */ green in red
136 : 0xff, /* ascr_Cb */ blue in cyan
137 : 0x00, /* ascr_Rb */ blue in red
138 : 0xff, /* ascr_Mr */ red in magenta
139 : 0x00, /* ascr_Gr */ red in green
140 : 0x00, /* ascr_Mg */ green in magenta
141 : 0xff, /* ascr_Gg */ green in green
142 : 0xff, /* ascr_Mb */ blue in magenta
143 : 0x00, /* ascr_Gb */ blue in green
144 : 0xff, /* ascr_Yr */ red in yellow
145 : 0x00, /* ascr_Br */ red in blue
146 : 0xff, /* ascr_Yg */ green in yellow
147 : 0x00, /* ascr_Bg */ green in blue
148 : 0x00, /* ascr_Yb */ blue in yellow
149 : 0xff, /* ascr_Bb */ blue in blue
150 : 0xff, /* ascr_Wr */ red in white
151 : 0x00, /* ascr_Kr */ red in black
152 : 0xff, /* ascr_Wg */ green in white
153 : 0x00, /* ascr_Kg */ green in black
154 : 0xff, /* ascr_Wb */ blue in white
155 : 0x00, /* ascr_Kb */ blue in black
156 : };

Hey, this looks useful.
Do you mind if I incorporate a variation of this into my SkyHigh kernel. Just an idea ATM to make it Synapse compatible and switchable etc. I'm sure it's doable
Won't be able to try for a few weeks though, still away and have some other kernel commitments on my return
Sent from my SM-N9005 using XDA Premium 4 mobile app

UpInTheAir said:
Hey, this looks useful.
Do you mind if I incorporate a variation of this into my SkyHigh kernel. Just an idea ATM to make it Synapse compatible and switchable etc. I'm sure it's doable
Won't be able to try for a few weeks though, still away and have some other kernel commitments on my return
Sent from my SM-N9005 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Actually, there is nothing here to do with kernel, stock kernel is already capable of loading profiles.
On the other hand, to load profile I do use Tasker so as for reloading on every screen on, 'cause it gets reset every time.
And I do understand that not every user can handle this with such creepy app like Tasker.
So implementing some easy way to handle choosing/loading/reloading plofiles sounds really useful.
The method and app I introduced here are only a comfortable way to investigate a profile structure and build a fine tuned, personolized profile for a particular display and taste. Further usage of that profile yet needs to be developed.

heyjoe66 said:
Actually, there is nothing here to do with kernel, stock kernel is already capable of loading profiles.
On the other hand, to load profile I do use Tasker so as for reloading on every screen on, 'cause it gets reset every time.
And I do understand that not every user can handle this with such creepy app like Tasker.
So implementing some easy way to handle choosing/loading/reloading plofiles sounds really useful.
The method and app I introduced here are only a comfortable way to investigate a profile structure and build a fine tuned, personolized profile for a particular display and taste. Further usage of that profile yet needs to be developed.
Click to expand...
Click to collapse
Yes, I understand that. I wish to add the control into Synapse, no need for scripts or other apps, that's all
I do have control for similar with my Note 3 kernel. I just might try implement some of it, stock or not.
Sent from my SM-N9005 using XDA Premium 4 mobile app

Ok, let me be the first who admits it, I have no glue how to calibrate the screen with your tools. Could you post a step by step guide or even Youtube video? That would be awesome.

Hi,
There is an application on the PlayStore : ColorTRUE
A workmate has the Colormonki Display calibration tool.
I will ask him share it to see how it works and if I can make a "real life" calibrated color screen.

Orphee said:
Hi,
There is an application on the PlayStore : ColorTRUE
A workmate has the Colormonki Display calibration tool.
I will ask him share it to see how it works and if I can make a "real life" calibrated color screen.
Click to expand...
Click to collapse
Hi,
(from app description)
Look for other ColorTRUE Aware Apps
Unlike your laptop or desktop operating system, Android mobile apps do not have system wide color management capabilities. Therefore, each app must apply color profiles individually. For this reason, X-Rite has created the ColorTRUE Aware Partner Program. We are currently collaborating with other app developers to allow them to seamlessly access your ColorTRUE profile so any app can display colors accurately and consistently. ColorTRUE Aware apps will be color managed once you create a profile with ColorTRUE. Just look for the ColorTRUE Aware logo for compatibility.
Click to expand...
Click to collapse
Looks like it doesn't use mdnie.

heyjoe66 said:
Hi,
(from app description)
Looks like it doesn't use mdnie.
Click to expand...
Click to collapse
You are right, I tried the display calibration tool, it only works in X-rite app.
I don't know if it can help, but I extracted ICC profile from data application.
mDNIe is quite obscure for me...
Edit : There is a tool to open ICC profiles here : http://www.color.org/profileinspector.xalter

Orphee said:
You are right, I tried the display calibration tool, it only works in X-rite app.
I don't know if it can help, but I extracted ICC profile from data application.
mDNIe is quite obscure for me...
Edit : There is a tool to open ICC profiles here : http://www.color.org/profileinspector.xalter
Click to expand...
Click to collapse
Not sure if I know what to do with this. I can see some values in the Profile Explorer you provided, but I have no idea, what threy mean.
I tried to read a bit about ICC, like here and here, but seriously, that's too much new info for me right now.
The most terrible thing about color here that bothers me is that color reproduction is heavily depend on screen brightness. With low brightness level grayscale goes totally green. I think I'll try to implement some callback for brightness changes in mdnie in kernel and apply some color correction there. Have no idea, how I'm gonna do that, but I'll try.

Do you want me to do a titanium backup of X-rite ColorTrue to leave you try it (with it own gallery)

Orphee said:
Do you want me to do a titanium backup of X-rite ColorTrue to leave you try it (with it own gallery)
Click to expand...
Click to collapse
Well, thanks indeed, but what I'm saying is that I have no idea how to correlate values from ICC with mdnie values. I don't know what values in ICC profile mean, some kind of coordinates of base RGB colors on some colorspace. I don't know how to translate them into values like red-in-black, red-in-green, red-in-white.
That's what problem is.
If you know anything about ICC profile structure, if can somehow describe all that values to me, maybe then we could figure out something to do with all that.

heyjoe66 said:
8. PROFILE WILL RESET AFTER SCREEN OFF/ON CYCLE. For now I'm using Tasker to refresh it on screen on event. Maybe later we'll figure out some more elegant way;
Click to expand...
Click to collapse
You can use a init.d script for profile reloading when screen is reactivated:
Code:
#!/system/bin/sh
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
sleep 1
fi
done &)
It's nothing else than a modified screenstate scaling script, i use that on my S2 and it works very good.
regards,
lombartz

lombartz said:
You can use a init.d script for profile reloading when screen is reactivated:
Code:
#!/system/bin/sh
(while [ 1 ]
do
AWAKE=`cat /sys/power/wait_for_fb_wake`
if [ $AWAKE = "awake" ]; then
echo 1 > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
echo "profile file name without path and spaces" > /sys/devices/platform/s5p-mipi-dsim.1/lcd/panel/mdnie/tuning;
fi
SLEEPING=`cat /sys/power/wait_for_fb_sleep`
if [ $SLEEPING = "sleeping" ]; then
sleep 1
fi
done &)
It's nothing else than a modified screenstate scaling script, i use that on my S2 and it works very good.
regards,
lombartz
Click to expand...
Click to collapse
Nice. That looks really useful. Sadly, these wait_for_fb_* attributes are missing on our device, or maybe moved to some place else. Need to look for them.
Regarding the problem you're referring to, it's actually a bug in samsung's code. They are trying to read profile from /sdcard when sdcard is not ready yet. I've fixed it in my own kernel build by moving the mdnie folder to /data. So now profile is updated as it meant to.

Can this be used to raise the gamma levels on the sm-t805 lollipop screen?

I have been playing around with this today but cant seem to get it to affect the color.
I have loaded up ABD, and loaded the DYNAMIC_UI profile into your little app but none of the sliders seem to affect anything on screen.
This is on a T800 running Cyanogenmod

Wow, I have a x-rite i1 display pro and it's working with color True application, can I load a profile at startup?

Astania said:
Wow, I have a x-rite i1 display pro and it's working with color True application, can I load a profile at startup?
Click to expand...
Click to collapse
Nope, thats not what this is for. I have the same piece of hardware but it only creates a profile that other apps can use if they support the x-rite sdk, such apps are nonexistent on Android except the x-rite app itself, and that app only works for displaying photos.
The mDNIe profiles are going to bare zero relation to the x-rite profiles so you cant use the x-rite profiles system wide even if you had the means.
I dont think there is enough dev backing on this to make it happen, but the ultimate goal would be to create a tool which is able to adjust the various settings of these profiles so it can be used in conjunction with a colorometer to create a color accurate profile that can be loaded up system wide.

Well, ICC profiles are universal standard, not only used by X-rite. X-rite is only making devices to measure color differences between the display and the standard.
So if you have another standard colour profile for display like mDNIe , you somehow must know what is a difference between a display you are profiling and standard, so you need a device to measure it.
Maybe there's a tool that can convert ICC to mDNIe profile?
It would be great to have possibility to turn on the display profiling at startup, especially that it can display wide range of AdobeRGB palette. ColorTrue app makes an ICC when you connect a profiler via USB and difference after and before profiling is huge. But profiles work only in the application, so it's not good.

Astania said:
Well, ICC profiles are universal standard, not only used by X-rite. X-rite is only making devices to measure color differences between the display and the standard.
So if you have another standard colour profile for display like mDNIe , you somehow must know what is a difference between a display you are profiling and standard, so you need a device to measure it.
Maybe there's a tool that can convert ICC to mDNIe profile?
It would be great to have possibility to turn on the display profiling at startup, especially that it can display wide range of AdobeRGB palette. ColorTrue app makes an ICC when you connect a profiler via USB and difference after and before profiling is huge. But profiles work only in the application, so it's not good.
Click to expand...
Click to collapse
Yup, I completely agree with what you are saying.
The screen on the Galaxy Tab S is really great, a very capable screen. But it's hampered by being locked to the few profiles Samsung provides.
Unfortunately mDNIe is a Samsung-only affair, and the tool posted earlier is full of sliders that seem to do nothing to the colour of the screen.
The profiles created by the X-Rite app are just a correction on top of a correction, this is fine and all as the chances of us getting low-level calibration seem non-existent, but there are no apps out whatsoever that actually use the X-Rite sdk (other than the x-rite app).
Without an advanced developer on board who knows all of this stuff inside out, I dont think we are going to get anywhere with conversion of mDNIe to ICC or anything like this.
The X-Rite app is great for photos, if there was any support for the X-Rite SDK in a video app this would be a good enough solution for me even if it is a correction on top of a correction, as colour accuracy in the OS is not important.

[REF] GT-I9305 hardware hacking

Dear Hardware Hackers, Geeks and Modders,
it always takes some time for me to switch over to a "new" device
Recently i bought a GT-I9305 for cheap, to be more exactely bought two; a broken and a working one.
Anyway, as always i need to disassemble my toys, see what's inside and investigate how things work out on the hardware base.
To follow my descriptions and findings in this thread it is recommended to grab the service manual, e.g. at cpkb.org.
As usual there are already many technical threads covering some of the hardware issues.
It's time to put some light on the unknown details here.
Starting a few weeks ago there'd been some time for reverse engineering, study documents, read posts and draw some conclusions.
I hope you'll enjoy my discoveries and give some feedback.
It might take some time though to write down everything even more detailed and get it little bit structured to post it here.
SD-card mode or complete brick recovery by re-write internal bootloader:
The sboot bootloader is capable to start from external SD-card as well and detects the media it has been started from.
To re-write the bootloader in the internal eMMC, we need an external boot media and block the internal boot process at power up.
The SD-card needs a special structure with the sboot binary right in place.
There's already a detailed thread about this procedure (see the reference links below).
Anyway, as you might have read elsewhere, replacing KNOX bootloader with an older one will not work.
The first time a KNOX bootloader is installed on the device,
some hardware protected blocks on the eMMC become active to meet the requirements of the KNOX function.
This process could not be reverted by simply overwrite the sboot section.
We need other tools for this. This might be covered later.
Prevent booting from internal eMMC by blocking MMC_CMD:
GT-I9300:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R313
GT-I9305:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R634
Please refer to the service manual for the correct position of the components.
Bootloader recovery will need some proof of concept, to be 100% certain that it works in the same way, as it does on GT-I9300.
SD-card booting by changing the CPU boot mode (permanently):
The boot code is set at power up by reading the logic level at special IO pins (XOM6:0).
These logic levels are set by a bunch of resistors and could be tweaked.
The boot modes for Exynos 4412 known so far:
Code:
XOM[5:1] : 1st device : 2nd device
5b'00010 : SDMMC_CH2 : USB
5b'00011 : eMMC43_CH0 : USB
5b'00100 : eMMC44_CH4 : USB
5b'10011 : eMMC43_CH0 : SDMMC_CH2
5b'10100 : eMMC44_CH4 : SDMMC_CH2
GT-I9305 (default, might need some approval by reading the registers):
Code:
XOM[5:1]
5b'10100 : eMMC44_CH4 : SDMMC_CH2
XOM0 : R612 10K PU
XOM1 : R614 100K PD
XOM2 : R615 100K PD
XOM3 : R609 10K PU
XOM4 : R616 100K PD
XOM5 : R610 10K PU
XOM6 : R617 100K PD
GT-I9305 (SD-card boot mode, needs testing!!!):
Code:
XOM[5:1]
5b'00010 : SDMMC_CH2 : USB
XOM0 : R612 10K PU (no change here)
XOM1 : R614 100K PD (no change here)
XOM2 : R615 10K PU (changed from PD to PU)
XOM3 : R609 100K PD (changed from PU to PD)
XOM4 : R616 100K PD (no change here)
XOM5 : R610 100K PD (changed from PU to PD)
XOM6 : R617 100K PD (no change here)
This relationship had been partly reverse engineered and concluded from other designs.
May need some approval though.
Same here, external booting from SD-card will need some proof of concept, to be 100% certain that it works without flaws.
There's a uncertainty concerning standard sboot, to allow a complete boot into system level (e.g. recovery) using a non default boot mode.
Maybe the code is bound to the device (internal eMMC only) in some way, or external SD-card is not fully supported as boot media.
Anyway, it is straight forward to build up a SD-card for testing.
The kernel boot parameter and parts of recovery image will need some tweaks to use the right device to boot from.
Direct access to Exynos 4412 debug UART:
The debug UART is permanently accessible on connector HDC401 (no need to block the USB port for this feature).
AP_TXD : HCD401, pin 11 (LVTTL 1.8V)
AP_RXD : HCD401, pin 17 (LVTTL 1.8V)
Please refer to the service manual for the position of connector HCD401.
These signals are fully tested and working.
The best would be to get the counter part of Panasonic AXE620124AW1 for a direct connection,
but this parts seems tobe hard to find.
As an alternative you'll need some very fine soldering iron and some tiny wires.
This way you could solder the wires directly to the pins of the connector.
You'll need some 1.8V level converter (+ USB UART) as already to be found in many projects.
Set up your terminal to 8N1 at 115200Bit/s and there you go.
E.g. enter S-Boot command line by hitting enter at boot up:
Code:
PMIC rev = PASS2(4)
cardtype: 0x00000007
SB_MMC_HS_52MHZ_1_8V_3V_IO
mmc->card_caps: 0x00000311
mmc->host_caps: 0x00000311
mmc_initialize: mmc->capacity = 30777344
Samsung S-Boot 4.0-1153417 for GT-I9305 (May 29 2013 - 17:22:39)
EXYNOS4412(EVT 1.1) / 2047MB / 15028MB / Rev 2 / I9305XXBME3
initialize_ddi_data: usable! (0:0x0)
PARAM ENV VERSION: v1.0..
init_fuelgauge: fuelgauge power ok
get_battery_detect: battery is missed
init_fuelgauge: battery is not detected, vcell(3858), soc(59)
init_fuelgauge: POR status
fuelgauge_por: POR start: vcell(3858), vfocv(3871), soc(59)
fuelgauge_por: update SDI M0 parameter
fuelgauge_por: RCOMP(0x0063), TEMPCO(0x0930)
fuelgauge_por: POR finish: vcell(3856), vfocv(3901), soc(55)
get_table_soc: vcell(3855) is caculated to t-soc(62.486)
init_fuelgauge: start: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_fuelgauge: finish: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL2:0x3b
init_microusb_ic: MUIC: CONTROL2:0x3b
PMIC_ID = 0x02
PMIC_IRQSRC = 0x00
PMIC_STATUS1 = 0x10
PMIC_STATUS2 = 0x00
PMIC_PWRON = 0x02
PMIC_IRQ1 = 0x0c
PMIC_IRQ2 = 0x00
s5p_check_keypad: 0x0
s5p_check_reboot_mode: INFORM3 = 0 ... skip
s5p_check_upload: MAGIC(0xc0c0c0c0), RST_STAT(0x10000)
microusb_get_attached_device: STATUS1:0x38, 2:0x00
s5p_check_download: 0
microusb_get_attached_device: STATUS1:0x38, 2:0x00
check_pm_status: chargable jig, LPM boot
AST_CHARGING..
cmu_div:1, div:7, src_clk:800000000, pixel_clk:57153600
s6e8ax0_read_id :: retry: 1
s6e8ax0_read_id :: 0xd1
<start_checksum:373>CHECKSUM_HEADER_SECTOR :4096
<start_checksum:375>offset:50, size:6296
<start_checksum:379>CHECKSUM_HEADER_INFO : NeedChecksum:0 PartNo:20
Not Need Movinand Checksum
Movinand Checksum Confirmation Pass
autoboot aborted..
S-BOOT #
S-BOOT # help
Following commands are supported:
* chipinfo
* help
* log
* reset
* boot
* load_kernel
* printenv
* setenv
* saveenv
* findenv
* checksum_need
* usb
* upload
* keyread
* readadc
* usb_read
* usb_write
* sdcard
* mmcdtest
* fuelgauge
To get commands help, Type "help <command>"
S-BOOT #
That's it by now!
Consider this as a starter, i'll try to add, correct or change some things from time to time and i hope it's human readable
Please give me some feedback or tell me your thoughts
I will add pics as soon as possible and further details if there's some interest.
I will also give some credits soon, because some of these findings are based on information from the curious around here
Credits:
AdamOutler
E:V:A
References:
GT-I9300 hard-brick-fix
http://forum.xda-developers.com/galaxy-s3/general/galaxy-s-iii-gt-i9300-hard-brick-fix-t1916796
Totally Revolutionary SDCard Bootloader For Galaxy S III
http://forum.xda-developers.com/galaxy-s3/general/totally-revolutionary-sdcard-bootloader-t2061437
Port SDCard Recovery to Other Exynos4412 Devices
http://forum.xda-developers.com/showthread.php?p=34732948
Knox reset
http://forum.xda-developers.com/showthread.php?t=2504258
eMMC sudden death research
http://forum.xda-developers.com/showthread.php?t=2096045
NOTE:
I am not responsible for any damaged devices.
The technical information may need some verification by experiments!
It would be nice to add a remark and refer to this post, if you use the pics and information from this thread :highfive:
Cheers,
scholbert

technical info, datasheets... stuff
eMMC function, structure and usage
1. Basic info
The onboard eMMC is the mass storage of our device.
There's much more under the hood, than you might expect and notice during normal usage within the OS.
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
If you upgraded to JB/KK bootloder another part is setup up and configured:
RPMB (KNOX counter, etc.)
I found no information about the size, but it's a multiple of 128K and may be set up between 128-512K.
Once activated the information stored in this area is controlled by internal security mechanism of eMMC.
Only trusted code is granted access and even worse, from a users sight it acts like OTP memory.
To get some info about the eMMC built in your device the sysfs entries are a good place to start.
We could grep the type of device form here, e.g. the eMMC in my GT-I9305 gives this output:
Code:
# cd /sys/class/block/mmcblk0/device
# cat name
MAG4FB
# cat manfid
0x000015
# cut -b 19,20 cid
f7 // this is the firmware revision in hex
# cat date
09/2012
See the datasheet attached (this is the exact part)
2. EFI partition and GPT
The first block of USER area of starts with traditional MBR.
Next block starts with the header for the EFI partition which is the base container for all other parts.
Code:
[SIZE="2"]45 46 49 20 50 41 52 54 Signature "EFI PART"
00 00 01 00 GPT version 1.0
00 02 00 00 header size 512 Bytes
5B DF 6D 84 CRC32 of header
00 00 00 00 reserved
01 00 00 00 00 00 00 00 Current LBA (location of this header copy)
FF 9F D5 01 00 00 00 00 Backup LBA (location of the other header copy)
22 00 00 00 00 00 00 00 First usable LBA for partitions (primary partition table last LBA + 1)
DE 9F D5 01 00 00 00 00 Last usable LBA (secondary partition table first LBA - 1)
41 4E 44 52 4F 49 44 20 4D 4D 43 20 44 49 53 4B ANDROID MMC DISK
02 00 00 00 00 00 00 00 Starting LBA of array of partition entries (always 2 in primary copy)
80 00 00 00 Number of partition entries in array
80 00 00 00 Size of a single partition entry (usually 128)
28 53 B2 A4 CRC32 of partition array
00 00 00 00[/SIZE]
The rest of this block is the GPT.
Reference:
http://en.wikipedia.org/wiki/GUID_Partition_Table
Other useful reading:
http://forum.xda-developers.com/showpost.php?p=31254495
3. PIT
This is another essential part of the USER area of eMMC and defines all partitions used by the OS.
Here's the definition of the internal structure:
Code:
[SIZE="2"]typedef int __s32;
typedef unsigned int __u32;
#define PARTITION_MAGIC 0x12349876
typedef struct _partition_header {
__u32 dwMagic; /* MAGIC CODE */
__s32 nCount; /* PARTITION (OneNAND + MOVINAND) */
/* PIT Option. */
__s32 dummy[5];
} __attribute__((packed)) partition_header;
typedef struct _partition_info {
__s32 nBinType; /* BINARY_TYPE_ (AP or CP?) */
__s32 nDevType; /* PARTITION_DEV_TYPE_ */
__s32 nID; /* PARTITION ID */
__s32 nAttribute; /* PARTITION_ATTR_ */
__s32 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
__u32 dwBlkSize; /* BLOCK SIZE / OFFSET IN BLOCKS */
__u32 dwBlkLen; /* BLOCK LENGTH */
__u32 dwOffset; /* FILE OFFSET (obsolete) */
__u32 dwFileSize; /* FILE SIZE (obsolete) */
char szName[32]; /* PARTITION NAME */
char szFileName[32]; /* FILE NAME */
char szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
} __attribute__((packed)) partition_info;[/SIZE]
Example:
Code:
[SIZE="2"]BOOTLOADER:
00 00 00 00 nBinType; /* BINARY_TYPE_ (AP or CP?) */
02 00 00 00 nDevType; /* PARTITION_DEV_TYPE_ */
50 00 00 00 nID; /* PARTITION ID */
02 00 00 00 nAttribute; /* PARTITION_ATTR_ */
01 00 00 00 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
00 00 00 00 dwBlkSize; /* BLOCK SIZE / BLOCK OFFSET */
C6 06 00 00 dwBlkLen; /* BLOCK LENGTH */
00 00 00 00 dwOffset; /* FILE OFFSET (in TAR) */
00 00 00 00 dwFileSize; /* FILE SIZE */
szName[32]; /* PARTITION NAME */
42 4F 4F 54 4C 4F 41 44 45 52 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szFileName[32]; /* FILE NAME */
73 62 6F 6F 74 2E 62 69 6E 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[/SIZE]
4. Complete partition table (GT-I9305)
Code:
[SIZE="2"]Block Size = 0x200
BOOT AREA:
Partition Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
BOOTLOADER sboot.bin 0x00000000 0x06C6 0x000D8C00 0x50 0x50
TZSW tz.img 0x000D8C00 0x0138 0x00027000 0x51 0x51
DDI-DATA (DATA) - 0x000FFC00 0x0001 0x00000200
USER AREA:
Partition Name Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
eMMC MBR (MBR) - 0x00000000 0x0001 0x00000200
EFI PART (GPT) - 0x00000200 0x0001 0x00000200
PIT m3.pit 0x00004400 0x0010 0x00002000 0x46 0x46
MD5HDR md5.img 0x00006400 0x0800 0x00100000 0x47 0x47
BOTA0 - 0x00400000 0x2000 0x00400000 0p1 0x01
BOTA1 - 0x00800000 0x2000 0x00400000 0p2 0x02
EFS efs.img 0x00C00000 0xA000 0x01400000 0p3 0x03
m9kefs1 m9kefs1.bin 0x02000000 0x2000 0x00400000 0p4 0x04
m9kefs2 m9kefs2.bin 0x02400000 0x2000 0x00400000 0p5 0x05
m9kefs3 m9kefs3.bin 0x02800000 0x2000 0x00400000 0p6 0x06
PARAM param.bin 0x02C00000 0x4000 0x00800000 0p7 0x07
BOOT boot.img 0x03400000 0x4000 0x00800000 0p8 0x08
RECOVERY recovery.img 0x03C00000 0x4000 0x00800000 0p9 0x09
RADIO modem.bin 0x04400000 0x2c000 0x05800000 0p10 0x0A
TOMBTONES tombstones.img 0x09C00000 0x80000 0x10000000 0p11 0x0B
CACHE cache.img 0x19C00000 0x200000 0x40000000 0p12 0x0C
SYSTEM system.img 0x59C00000 0x300000 0x60000000 0p13 0x0D
HIDDEN hidden.img 0xB9C00000 0x118000 0x23000000 0p14 0x0E
OTA - 0xDCC00000 0x4000 0x00800000 0p15 0x0F
USERDATA userdata.img 0xDD400000 0x0000 0p16 0x10
[/SIZE]
5. DDI-DATA
In the hidden boot0 partition the values like the flash count are stored.
Triangle away is able to modify this data.
It's stored at 0x000FFC00 on the boot0 partition of emmc.
Code:
struct ddi_data {
int magic; // must be 0x12340012
int custom_flash_count;
int odin_count;
int binary_type; // 0 = samsung official, 1 = custom, 2 = "Unknown"
char model_name[16];
int rom_type; // this is the first 4 bytes of the decrypted 16 bytes
in the param partition. 0xFF000000 = samsung, 0xEE000000 = custom }
For details please refer to this post:
http://forum.xda-developers.com/showthread.php?p=28953690#post28953690
Further useful reading:
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Thesis:
Remove KNOX bit by eMMC low level format command:
With KNOX activation at booloader level, there's an area which stores the KNOX bit information called RPMB.
During research of the eMMC sudden death, some firmware files for the eMMC controller had been reverse engineered and some of the custom commands had been discovered.
Read this and follow ups:
http://forum.xda-developers.com/showpost.php?p=49548099&postcount=121
By changing the boot mode and boot up completely from SD-card into special recovery, it might be possible to send this command with a tool called mmc-utils:
https://github.com/BenGardiner/mmc-utils
Because this will wipe out everything, it would be a great adventure and you'll need a proper backup of all significant parts from the internal eMMC. Otherwise device specific parameters will be lost forever.
See this remark as a reference as well:
http://forum.xda-developers.com/showpost.php?p=51297844&postcount=135
I'll spent some time to think about a useful SD-card layout... :laugh:
TBC
scholbert

All this looks knowledgeable
How are you at ROM/Kernel building?

Hi f0xy!
f0xy said:
All this looks knowledgeable
Click to expand...
Click to collapse
Thanks for this feedback!
I know these experiments are only for the fearless with good eyes.
For the average user there's no need to hack boot mode or stuff, unless there's some evil bricked device
I guess folks need pix
f0xy said:
How are you at ROM/Kernel building?
Click to expand...
Click to collapse
Depends...
On a hobbyist level i build many kernels, tweaked drivers and kernel code for personal use over the years.
Little less if we speak about building ROMs.
I might help out on some issues, but don't count on me for bigger projects.
Time is always lacking and often i'm too lazy to clean up the code for git
Cheers,
scholbert

Hi,
just added the complete partition table for GT-I9305 and some other stuff in the second post...
I try to sum up facts floating around as well and put it in the context of GT-I9305, so some info here is no breaking news
Anyway, enjoy the tech ride!
Regards,
scholbert

@mad_ady I seen your post in boeffla, some info here may be of help? Or maybe the @op can provide some help for you?
Regards

Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?

Hi mad_ady!
mad_ady said:
Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?
Click to expand...
Click to collapse
Yeah i guess other devices with onboard eMMC use GPT tables as well.
Though it is not completely clear at which level these are accessed.
I assume that the bootloader or even kernel is able to read this table during start up and is also aware of the sizes and boundaries.
The PIT table plays another role in this game.
AFAIK this is the reference for Odin/Heimdall and should match GPT boundaries.
Some experts are needed to confirm this or i'll have to dig a little deeper myself
Regards,
scholbert

Hi there,
i made a comparison between the cmdline passed to the kernel by "old" and "new" bootloaders.
Just started some investigation to fix "offline charging" with KK stock running on devices which still got the old bootloader.
Here's the default cmdline "old" vs. "new":
Code:
[SIZE="2"]JB 4.1.2 (I9305XXBME3) KK 4.4.4 (I9305XXUFNJ1)
console=ram console=ram
loglevel=4 loglevel=4
androidboot.baseband=mdm androidboot.baseband=mdm
sec_debug.level=0 sec_debug.level=0
sec_watchdog.sec_pet=5 sec_watchdog.sec_pet=5
androidboot.debug_level=0x4f4c androidboot.debug_level=0x4f4c
[email protected] [email protected]
- [email protected]
- [email protected]
s3cfb.bootloaderfb=0x5ec00000 s3cfb.bootloaderfb=0x5ec00000
lcdtype=96 lcdtype=96
consoleblank=0 consoleblank=0
lpcharge=0 -
lpj=3981312 lpj=3981312
vmalloc=144m vmalloc=176m
oops=panic oops=panic
pmic_info=67 pmic_info=67
cordon=<32-Byte hash value> cordon=<32-Byte hash value>
- connie=GT-I9305_OPEN_EUR_<32-Byte hash value>
androidboot.emmc_checksum=3 androidboot.emmc_checksum=3
- androidboot.boot_salescode=
- androidboot.odin_download=1
androidboot.bootloader=I9305XXBME3 androidboot.bootloader=I9305XXUFNJ1
- androidboot.selinux=enforcing
- androidboot.warranty_bit=1
- androidboot.sec_atd.tty=/dev/ttySAC2
androidboot.serialno=<16-Byte serial> androidboot.serialno=<16-Byte serial>
snd_soc_core.pmdown_time=1000 snd_soc_core.pmdown_time=1000[/SIZE]
As you might see there's the keyword lpcharge, which is not present on the "new" bootloaders.
On the new bootloaders there's the additional parameter android.bootmode=charger, if you start up with a charger plugged in.
On KK stock some proprietary binaries identify this keyword to activate offline charging.
Some kernel drivers (battery) react to this string as well and there's a patch already.
There'd been some attempts to fix this in initial ramdisk by hi-jacking cmdline present in /proc/cmdline and replace lpcharge=1 with android.bootmode=charger .
My first idea was, to make use of a similar function at kernel level and append android.bootmode=charger to the "old" bootloader cmdline, if lpcharge is set to 1 (similar to a conditional CONFIG_CMDLINE_EXTEND function).
The kernel itself will put this in /proc/cmdline afterwards and user space tools will be satisfied.
Some years ago i tweaked some kernel code for Archos tablets, which made use of custom ATAG keys to hand over some device specific parameters. Maybe i'll get something out of it
For my personal reference:
http://forum.xda-developers.com/galaxy-tab-3/general/kitkat-t31x-t2892792/post55863790#post55863790
TBC
Cheers,
scholbert

Hello.
Thanx for your Thread. For some summary about I9300 and I9305.
:good:
Please I need some input for my low brain...
I'm playing with I9300 and Tizen RD-PQ stuff...
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Thanx for every input.
Best Regards

The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n

Hi!
adfree said:
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
Click to expand...
Click to collapse
See mad_ady's comment:
mad_ady said:
The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n
Click to expand...
Click to collapse
From kernel level it is only possible to dump user area (unless you use a specific kernel with mmcblk0boot0 and mmcblk0boot1 enabled).
Read again this quote form my second post:
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
Click to expand...
Click to collapse
adfree said:
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
Click to expand...
Click to collapse
Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
adfree said:
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Click to expand...
Click to collapse
Nope... it's at the very start of eMMC in a seperate area, normally hidden from user (see my comments above).
See datasheet attached, maybe this helps to understand how eMMC works.
EDIT:
Found the exact part which is soldered on my GT-I9305 mainboard.
See second post for reference as well:
http://forum.xda-developers.com/showpost.php?p=56747098&postcount=2
I'll leave this older datasheet her as well... this is at least a similar part.
Good luck and best regards,
scholbert

Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
Click to expand...
Click to collapse
I have problems to check my progress... because broken/damaged Display...
I see only black...
In Android I can use ADB stuff to see something...
Writing 32 MB RD-PQ dump not kill I9300... (no idea if this could kill IMEI, EFS or other Security stuff)
But I can't see where it hangs or if something is on Display...
Writing only s-boot-mmc.bin (200 KB sboot) from RD-PQ...
I have no idea yet, how to check if really written or ignored by I9300 sboot...
Code:
getprop ro.bootloader
Gives no anwser...
And this feature looks like Kernel related stuff...
Example why I am unsure if 200 KB sboot is accepted...
In I9300 you can find easily string ODIN in sboot...
But in RD-PQ is no ODIN text string... then why my I9300 works without problems with Odin...
I need some time to buy cheap working Display...
So I can see "visual effects" on Display...
1 goal would be this:
SDCARD MODE
COPY BINARY FROm SDCARD..
COPY BINARY TO EMMC..
SDCARD DOWNLOAD COMPLETED.
Click to expand...
Click to collapse
In Tizen world it seems mandatory to restore uboot... it contain the THOR string for THOR Downloader...
https://lists.tizen.org/pipermail/general/2013-November/002707.html
For me it is not clear enough... if RD-PQ sboot loads uboot...
sboot AND uboot is executed...
OR it is or feature...
Only uboot could be enough to executed...
About dump mmcblk0...
Code:
dd if=/dev/block/mmcblk0 skip=0 count=10000000 of=/sdcard/dump_v1.bin
dd if=/dev/block/mmcblk0 skip=10000000 count=10000000 of=/sdcard/dump_v2.bin
dd if=/dev/block/mmcblk0 skip=20000000 of=/sdcard/dump_v3.bin
This seems to work... but last 1 is again 11 GB + big...
It starts after with beginning...
I need proper count value... need some time and calculator...
I hope next week I have working Display for my testdevice...
Best Regards

eMMC hacking.... SD card boot... remove KNOX bootloader... finally?
Hi again,
i'd like to refer to a software package which seems to have leaked from a service center or similar some time ago.
Please refer to this thread, which explains how to revive hard bricked S3 devices and other Exynos devices:
http://forum.xda-developers.com/galaxy-s3/general/samsung-s3-i9300-note2-n7100-i9500-s4-t2647558
I found this package at several other places in the web as well, and it might be useful for some smart experiments :angel:
Here's what i got from it...
S3 repair contains a test suite for low level tests and tasks to setup up S3 from scratch.
You'll have to prepare a MicroSD card with a low-level tool (similar to dd command in linux).
The write script gives an idea about the offsets used on the SD card (multiples of 512 bytes), so i translated those to hex values:
emmc_auto.sbl.bin:1:499OFF: 0x00000200 LEN: 0x0003e600
E4412_S.TN.bl1.bin:9500:16OFF: 0x004a3800 LEN: 0x00002000
S5E4412_asb.bin:20000:40000OFF: 0x009c4000 LEN: 0x01388000
asb.ramfs:80000:97000OFF: 0x02710000 LEN: 0x02f5d000
From what i got by investigating the hex data of these binaries, the functions should be:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- S5E4412_asb.bin -> a standalone tool and testsuite compiled as a ready to run binary (no elf format here!)
- asb.ramfs -> a proprietary RMFS formatted ramdisk which carries some test files (e.g. test pattern, test videos, etc.)
A quite interesting piece of code is the S5E4412_asb.bin file.
So grepping some strings in this binary file gave this section, which is responsible for
vendor boot size change with CMD62 (refer to the eMMC datasheet as well) and seems to restore the bootloaders:
Code:
0x093DB6 0x2B APP STEP] Step 1. BL Download Address Set
0x093DE6 0x2D APP STEP] Step 2. DRAM Download Address Set
0x0943CA 0x0A NA,\NA0\NA
0x0943D6 0x0A NA$\NA(\NA
0x0943FE 0x2D APP STEP] CMD 0xEFAC62EC : RESPONSE 0x%08x %
0x094432 0x2B APP STEP] CMD 0xCBAEA7 : RESPONSE 0x%08x %
0x094462 0x32 APP STEP] Boot Partition Size : RESPONSE 0x%08x %
0x09449A 0x32 APP STEP] RPMB Partition Size : RESPONSE 0x%08x %
0x09472A 0x24 APP STEP] CMD 6 : RESPONSE 0x%08x %
0x094756 0x2B APP STEP] BL1 & BL2 loading Address : 0x%x
0x094786 0x2C APP STEP] Dram Image loading Address : 0x%x
0x0947B6 0x34 APP STEP] BL1 & BL2 compare address for Read : 0x%x
0x0947EE 0x35 APP STEP] Dram Image compare address for Read : 0x%x
As user Oranav pointed out in the eMMC sudden death research thread, there might be commands
which should initiate low level formatting of the eMMC chip:
CMD62 (ARG: 0xEFAC62EC)
CMD62 (ARG: 0xFAC0021)
This might probably delete all the chip metadata (incl. wear leveling state and bad block info)
and if these commands are correct, it will also reset KNOX counters and stuff.
In other words this is a full factory wipe of eMMC cells.
These are some snippets in S5E4412_ASB.bin located at:
0x8A41C0:
Code:
A5 A2 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
71 1F 04 00
AB C2 9E FF
5A 7B B6 F0
83 68 AE 0F
CD 12 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
1D 28 04 00
...and again at:
0x8C43F0
Code:
2D A2 04 00
CD A4 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
AB C2 9E FF
5A 7B B6 F0
9F 1B 04 00
83 68 AE 0F
47 0F 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
This could be some approval for the usage of these commands at least, because these sections are pure ARM assembly and seem to be associated with eMMC low level setup.
I'll have to find out some offsets for this machine code to try a disassembly.
Maybe this will lighten things up even more.
EDIT:
BTW, found one of the main return addresses which is at 0x40008000 (physical address at the beginning of DRAM). Let's see if this is correct.
EDIT2:
Bingo... just had a look in my boot logs i once grepped during UART session:
Starting kernel at 0x40008000...
Conclusion:
The ASB test suite (S5E4412_asb.bin) is booted/started at the same offset as the linux kernel does.
Let's see what this may give us
Another thing to mention is, that included in S5E4412_asb.bin there's a M0 test bootloader (GT-I9300).
Have a look at offset 0x08d8fe8 inside the binary
So in the end i wonder, if someone has ever used this "Service" card together with a real UART connection to the board.
Apart from the automated test and setup process, my guess is, that there should be some command line or some kind of a test menu which may give alternative choices to proceed certain tasks.
P.S.: Maybe it's hard to understand what i like to point out here... but imagine we use the following:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- recovery.img -> kernel + recovery to start completely from SD card (eMMC not touched here!!!)
P.P.S: Let's see if the SD card boot files look for a signature here.....
Stay tuned!
scholbert

... further experiments
Hi,
i made further progress with my attempts to boot my GT-I9305 completely from external MicroSD.
As proposed in my last post i prepared a card with the following commands:
Code:
echo "Exynos4412 FWBL1+BL2"
dd if=./emmc_auto.sbl.bin of=/dev/sda bs=512 seek=1
echo "Exynos4412 TZSW"
dd if=./E4412_S.TN.bl1.bin of=/dev/sda bs=512 seek=9500
Next is to prepare the board.
You'll need Anyway JIG or a dedicated UART connection as described in my first post.
To block access to internal eMMC the resistor R634 on the GT-I9305 mainboard got shorted.
Insert the MicroSD with the proprietary boot files into the socket.
Connect to a terminal and attach supply voltage of 3.8-4.0V to the battery connector.
Press the power button and hold it.
Here's the output so far:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422650 usec
<OK>
Inp32(uAddr) : 0x0
LINUX Bootingøq!ñ¥¡Õ
At this point there are no further outputs, as there's nothing to be executed.
Like known from the sboot, hitting enter on your terminal from the very beginning gives a commandline interface.
Unfortunately, it seems that the watchdog is not stopped at this point and maybe the PMIC is not fully initialized.
This leads to repeated resets.
Anyway if you're fast enough, you may get this command list from the proprietary bootloader:
Code:
BL>help
CMD LIST
LOG
WAIT
USB
GET
JUMP
RUN
RUN2
INIT
INIT2
DMC
CLK
DVFS
ASV
DVFSQA
EMA
PMIC
SD
EMMC
ZIP
ABB
RESET
DUMP
MEMCPY
MEMCMP
MEMSET
OUTP32
INP32
SETBITS
GETBITS
COPYRUN
MEMCPY_RUN
PATTERN
BOOT
CTA
ASB
COM
HELP
H
TEST
TN
<OK>
BL>
Some of these commands play an important role for starting up the ASB test suite if present.
These command are included in BL2 and they seem to be interpreted by ASB:
Code:
TN M0|PMIC
INIT2 3|init2|TEST
EMMC
0x10020800 1|TEST RUN
I started to mod these, but as far as i did not start the ASB image yet there's nothing to observe.
By looking at other logs from brick recoveries, i found a relationship between the first output of ASB and these commands.
My idea is that by changing these we could influence the behaviour of the ASB code for educational purpose.
As described above, without parts of ASB the PMIC seems not to be fully initialized,
because i found out that you need to hold the power button to keep the board alive.
This is little strange, as i am pretty sure that this was not the case in the begining, but maybe i'm wrong.
Anyway as far as i observed it, the board starts normally from internal eMMC after my experiments had finished.
At least nothing indicates that something got damaged...
Just to check out what happens i put a raw recovery image at position 20000 (0x9c4000) on the card.
This is the beginning of kernel code.
Afterwards i started a new terminal session and i saw that the first command of kernel code got printed,
but unfortunately after the bootcode jumps to this code there's no further output.
Something is still missing.
Could be something obvious (e.g. missing TAGS at 0x40000100) or could be not.
Maybe it would be a good idea to compile a version of u-boot and try again.
Let's see
scholbert

....grrrr
Hi again!
First of all, nice to see that at least two guys follow my binary surgery.
Second, i must admit that the platform is not that responsive as i first thought.
Due to all this signing stuff, it is easy to break something and CPU simply stops executing code.
So for now there's nothing, than further logging outputs from the console.
1. I removed some of the start up commands from BL2, which leaves TN M0|PMIC & INIT2 3|init2|TEST for ASB code.
This is what i got then:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[CHIPID] E4412 EVT1.1
LOTID WNO X Y IDS HPM ASV_GRP FUSE SHIFT
[LOG]N571A 18 201 195 22 22 8 -1 100000 80
There's no auto booting anymore at this point.
2. I put anything back, apart from the RUN command.
During this test i used a modified ASB binary with sboot from I9305XXALI4 put in the right place.
Unfortunately the output stops after "FW Booting"
The device kept being powered though. Which is a good thing from my guess.
Here's the log:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422818 usec
<OK>
Inp32(uAddr) : 0xea00007e
FW Booting
Right now it's a bit to early for further conclusions, but maybe the signing stuff got broken at some point in both cases.
It could also be that some of the signatures is especially for GT-I9300, or in other words the CPU on GT-I9305 uses a different key set.
That's it by now, but i won't give up yet
Cheers,
scholbert

Wow, that's one of the most insightful threads about 4412 I've seen for a while.
Replying here on OP's PM for further reference:
* At LenovoK860 uboot sources:
These seem to contain private keys for some batch of 4412 - that's the first time I see private signing keys of any Exynos to leak. Previous leaks were just wild security-dropping bootloader stages signed with private keys, but no keys included.
These keys can either match batch customized for Lenovo or match all 4412 (Exynos4 public key hash fuses, in theory, meant to be factory/OEM customizable) - I'd say the latter since neither GS3 or any common device built on S5PC2xx I've seen was expected to have any grade of real security, so probably neither Lenovo or Samsung cared to customize any of Exynoses used around.
There is a way to check it by comparing dumps from 0x10100000 area between GS3 and LenovoK860 CPUs (I'm uncertain, as I'm really rusty). Probably there's also other way by comparing Lenovo stage1 public keys with GS3 0x1010_0000 dumps, considering how pubkey is validated against these bits (no idea, don't remember).
* At My and Adam's tries:
We were quite succesfull in running UBoot on I9300 and GalaxyCam GC100.
What we couldn't achieve was kernel booting - Exynos4 kernels require TZSW to be fully operating and communicating with it. I couldn't get it to load up properly.
There's quite of history of our tries under https://github.com/Rebell/exynos4_uboot/commits/master
Another option is, of course, disabling TZSW support in kernel and not booting it at all - it doesn't seem to work out-of-the-box either, and would make impossible to boot any non-modded kernels.
AFAIR (and boy, was it while ago), referenced sources were building and fusing to the SD card flawelessly and supporting both fastboot and UART terminal with most (all?) of the commands working (yes, it can do raw R/W to eMMC and whatnot in SVC mode without TrustZone supervisor interfering, because it's not loaded at all yet). Just kernel wouldn't boot. I'd say you should give it a try (if you didn't already).
The crucial part we used there was FWBL1 (there https://github.com/Rebell/exynos4_uboot/tree/master/sd_fuse) - first, already signed, stage of bootloader hat's doing nothing but loading another stage of bootloader without any security (kudos to Odroid).
We couldn't find any equivalent of signed FWBL1 for Exynos4210 (GS2 CPU) that would allow us booting eMMC hardbricked GS2 devices.
* At ASB:
First time I hear of it. Never seen this stuff before.

... just an update
Hi,
it's been a while now that i found some time to fiddle around with one of my i9305 mainboards.
In the meantime there'd been some nice conversation via PM with Rebellos as well.
u-boot on Galaxy S3
Find the sources here:
https://github.com/Rebell/exynos4_uboot
So i finally gave it a try, jumped on his work and compiled a version of u-boot for Galaxy S3 devices.
As a prerequisite you'll have to block eMMC and to make it short...
It just works!!!
Attached you'll find a log from external sdcard boot.
Maybe i'll do some tweaks in the near future, e.g. remove the annoying "pmic_s5m8767_init" messages,
as there is no such device on our S3.
s-boot for Tizen on Galaxy S3
On the Tizen Wiki (https://wiki.tizen.org/wiki/Flash_Tizen_2.2.1_Image_to_Reference_Device)
there's a link to a tar with image files (Tizen_RD-PQ_System_20131107_1.tar), which contains a s-boot file.
Unfortunately the signature of BL1 inside the s-boot image seems not fit the mass production units.
In other words no boot message here at all... at least while trying to boot from sdcard.
mass production sboot on external SD-card
On the other hand the mass production units sboot images are ready to boot from sdcard as well.
Find the second log attached below.
The error messages are normal, because i blocked eMMC all the time, to prevent bricking during my experiments.
security key validation
As you'll see in the logs i dumped the region at 0x10100000 for the security key values.
Here's a snippet of the secure boot function header in the u-boot sources:
Code:
#define MAX_EFUSE_DATA_LEN 16
typedef struct
{
unsigned char rsa_n[128]; /* RSA Modulus N */
unsigned char rsa_e[4]; /* RSA Public Exponent E */
} RawRSAPublicKey;
typedef struct
{
RawRSAPublicKey rsaPubKey; /* RSA PublicKey */
unsigned char signedData[20]; /* HMAC Value of RSA PublicKey */
} PubKeyInfo;
/* Secure Boot Context */
typedef struct
{
RawRSAPublicKey stage2PubKey; /* Stage2 RSA Public Key */
unsigned char code_SignedData[128]; /* RSA Signature Value */
PubKeyInfo pubKeyInfo; /* Stage1 RSA PublicKey and it's HMAC value */
unsigned char func_ptr_BaseAddr[48]; /* Function pointer of iROM's secure boot function */
unsigned char test_eFuse[MAX_EFUSE_DATA_LEN];
unsigned char reservedData[36];
} SecureBoot_CTX;
If i assume S3 still uses V1.1 security with 1024Bit RSA (BL1.bin is 8192Byte) the efuse key would be 128Bit, which results in 4 registers with 32Bit length.
Exported to a hex dat file this is 16Byte of Hex data.
Dump at 0x10100000 gives:
Code:
10100000: 0d19a391 2a0502af 1576987a 212121bc .......*z.v..!!!
We'll have to re-arrange the bytes for little endian order:
Code:
91a3190d af02052a 7a987615 bc212121
... use a hex-editor and put these into a file named: eFuseData.dat
Next i took codesigner_v21 and tried to validate stock BL1 files if they match.
codesigner_v21 -v1.1 <BL1.bin> <eFuseData.dat> -VERIFY
Unfortunately no succes yet... signature verification always failed.
This is a mistery, because the position of the key should be correct and i used valid bootloader files as well.
Anyway this had been only a proof of concept if we got the right tool and the right efuse values.
TBC
Cheers,
scholbert

@scholbert
Please, need collection of GT-I9305 Bootloader....
Something like this:
http://forum.xda-developers.com/galaxy-s3/general/guide-extract-bootloader-make-flashable-t2864264
http://forum.xda-developers.com/galaxy-s3/general/ref-galaxy-s3-stock-kernel-bootloaders-t2189063
For now I was only able to find
RESTORE_BOOTLOADER_I9305XXALI4.zip
http://forum.xda-developers.com/showpost.php?p=32760677&postcount=1
I need few more for stupid tests.
For now my test GT-I9300 PCB is able to start this sboot.bin from GT-I9305... with tweezer.
sboot.bin is copied successfully... but not start in "normal mode"...
Here I can see other method... sboot.bin is not copied to eMMC but fully executed from eMMC, with Boot menu:
http://forum.xda-developers.com/showpost.php?p=64664423&postcount=278
I will check if GT-I9305 has similar Bootloader and if it will executed on my GT-I9300 test PCBs.
Thanx in advance.
Best Regards

I found this:
I9305XXUFNL1-DBT.zip
Here is sboot.bin from GT-I9305 inside... I have attached.
Search for text String THOR... you can find:
Code:
- Thor is connected!
This could mean... I9305 is Tizen enebled... not only this...
Chance to play with U-Boot.
Tried on I9300 with no luck...
Volume + or Volume - do nothing... maybe Hardware Keys different...
I hope to find something working for my I9300...
Btw.
First time I saw THOR string also in Note 4 N910C:
http://forum.xda-developers.com/showpost.php?p=64663039&postcount=65
Best Regards

Do anyone know about this log ? (RILQ/RILD log)

My V20(US996) can't connect mobile cellular data. I use the V20 on CDMA EVDO Network.
The logcat is shown this log when connect mobile data network.
04-06 15:39:11.841 1552 1706 E RILQ : (0/1552): RIL[0][main] qcril_data_set_ril_profile_id: RIL provided [3] profile id. This is currently not supported
04-06 15:39:11.863 1552 1706 E RILQ : (0/1552): RIL[0][main] qcril_data_request_setup_data_call: unable to setup data call, index [0]
04-06 15:39:11.863 1552 1706 E RILQ : (0/1552): RIL[0][main] qcril_data_request_setup_data_call: qcril_data_request_setup_data_call: EXIT with FAILURE
What is mean?
How can I solve the problem?
Please give help everyone. Thanks. Have a nice day!

reference this for code ( 3)
Code:
ypedef enum {
RIL_E_SUCCESS = 0,
RIL_E_RADIO_NOT_AVAILABLE = 1, /* If radio did not start or is resetting */
RIL_E_GENERIC_FAILURE = 2,
RIL_E_PASSWORD_INCORRECT = 3, /* for PIN/PIN2 methods only! */
RIL_E_SIM_PIN2 = 4, /* Operation requires SIM PIN2 to be entered */
RIL_E_SIM_PUK2 = 5, /* Operation requires SIM PIN2 to be entered */
RIL_E_REQUEST_NOT_SUPPORTED = 6,
RIL_E_CANCELLED = 7,
RIL_E_OP_NOT_ALLOWED_DURING_VOICE_CALL = 8, /* data ops are not allowed during voice
call on a Class C GPRS device */
RIL_E_OP_NOT_ALLOWED_BEFORE_REG_TO_NW = 9, /* data ops are not allowed before device
registers in network */
RIL_E_SMS_SEND_FAIL_RETRY = 10, /* fail to send sms and need retry */
RIL_E_SIM_ABSENT = 11, /* fail to set the location where CDMA subscription
shall be retrieved because of SIM or RUIM
card absent */
RIL_E_SUBSCRIPTION_NOT_AVAILABLE = 12, /* fail to find CDMA subscription from specified
location */
RIL_E_MODE_NOT_SUPPORTED = 13, /* HW does not support preferred network type */
RIL_E_FDN_CHECK_FAILURE = 14, /* command failed because recipient is not on FDN list */
RIL_E_ILLEGAL_SIM_OR_ME = 15 /* network selection failed due to
illegal SIM or ME */
} RIL_Errno;
typedef enum {
RIL_CALL_ACTIVE = 0,
RIL_CALL_HOLDING = 1,
RIL_CALL_DIALING = 2, /* MO call only */
RIL_CALL_ALERTING = 3, /* MO call only */
RIL_CALL_INCOMING = 4, /* MT call only */
RIL_CALL_WAITING = 5 /* MT call only */
} RIL_CallState;
typedef enum {
RADIO_STATE_OFF = 0, /* Radio explictly powered off (eg CFUN=0) */
RADIO_STATE_UNAVAILABLE = 1, /* Radio unavailable (eg, resetting or not booted) */
RADIO_STATE_SIM_NOT_READY = 2, /* Radio is on, but the SIM interface is not ready */
RADIO_STATE_SIM_LOCKED_OR_ABSENT = 3, /* SIM PIN locked, PUK required, network
personalization locked, or SIM absent */
RADIO_STATE_SIM_READY = 4, /* Radio is on and SIM interface is available */
RADIO_STATE_RUIM_NOT_READY = 5, /* Radio is on, but the RUIM interface is not ready */
RADIO_STATE_RUIM_READY = 6, /* Radio is on and the RUIM interface is available */
RADIO_STATE_RUIM_LOCKED_OR_ABSENT = 7, /* RUIM PIN locked, PUK required, network
personalization locked, or RUIM absent */
RADIO_STATE_NV_NOT_READY = 8, /* Radio is on, but the NV interface is not available */
RADIO_STATE_NV_READY = 9 /* Radio is on and the NV interface is available */
} RIL_RadioState;
typedef enum {
RADIO_TECH_UNKNOWN = 0,
RADIO_TECH_GPRS = 1,
RADIO_TECH_EDGE = 2,
RADIO_TECH_UMTS = 3,
RADIO_TECH_IS95A = 4,
RADIO_TECH_IS95B = 5,
RADIO_TECH_1xRTT = 6,
RADIO_TECH_EVDO_0 = 7,
RADIO_TECH_EVDO_A = 8,
RADIO_TECH_HSDPA = 9,
RADIO_TECH_HSUPA = 10,
RADIO_TECH_HSPA = 11,
RADIO_TECH_EVDO_B = 12,
RADIO_TECH_EHRPD = 13,
RADIO_TECH_LTE = 14,
RADIO_TECH_HSPAP = 15 // HSPA+
} RIL_RadioTechnology;
// Do we want to split Data from Voice and the use
// RIL_RadioTechnology for get/setPreferredVoice/Data ?
typedef enum {
PREF_NET_TYPE_GSM_WCDMA = 0, /* GSM/WCDMA (WCDMA preferred) */
PREF_NET_TYPE_GSM_ONLY = 1, /* GSM only */
PREF_NET_TYPE_WCDMA = 2, /* WCDMA */
PREF_NET_TYPE_GSM_WCDMA_AUTO = 3, /* GSM/WCDMA (auto mode, according to PRL) */
PREF_NET_TYPE_CDMA_EVDO_AUTO = 4, /* CDMA and EvDo (auto mode, according to PRL) */
PREF_NET_TYPE_CDMA_ONLY = 5, /* CDMA only */
PREF_NET_TYPE_EVDO_ONLY = 6, /* EvDo only */
PREF_NET_TYPE_GSM_WCDMA_CDMA_EVDO_AUTO = 7, /* GSM/WCDMA, CDMA, and EvDo (auto mode, according to PRL) */
PREF_NET_TYPE_LTE_CDMA_EVDO = 8, /* LTE, CDMA and EvDo */
PREF_NET_TYPE_LTE_GSM_WCDMA = 9, /* LTE, GSM/WCDMA */
PREF_NET_TYPE_LTE_CMDA_EVDO_GSM_WCDMA = 10, /* LTE, CDMA, EvDo, GSM/WCDMA */
PREF_NET_TYPE_LTE_ONLY = 11 /* LTE only */
} RIL_PreferredNetworkType;
/* Source for cdma subscription */
typedef enum {
CDMA_SUBSCRIPTION_SOURCE_RUIM_SIM = 0,
CDMA_SUBSCRIPTION_SOURCE_NV = 1
} RIL_CdmaSubscriptionSource;
/* User-to-User signaling Info activation types derived from 3GPP 23.087 v8.0 */
typedef enum {
RIL_UUS_TYPE1_IMPLICIT = 0,
RIL_UUS_TYPE1_REQUIRED = 1,
RIL_UUS_TYPE1_NOT_REQUIRED = 2,
RIL_UUS_TYPE2_REQUIRED = 3,
RIL_UUS_TYPE2_NOT_REQUIRED = 4,
RIL_UUS_TYPE3_REQUIRED = 5,
RIL_UUS_TYPE3_NOT_REQUIRED = 6
} RIL_UUS_Type;
/* User-to-User Signaling Information data coding schemes. Possible values for
* Octet 3 (Protocol Discriminator field) in the UUIE. The values have been
* specified in section 10.5.4.25 of 3GPP TS 24.008 */
typedef enum {
RIL_UUS_DCS_USP = 0, /* User specified protocol */
RIL_UUS_DCS_OSIHLP = 1, /* OSI higher layer protocol */
RIL_UUS_DCS_X244 = 2, /* X.244 */
RIL_UUS_DCS_RMCF = 3, /* Reserved for system mangement
convergence function */
RIL_UUS_DCS_IA5c = 4 /* IA5 characters */
} RIL_UUS_DCS;
/* User-to-User Signaling Information defined in 3GPP 23.087 v8.0
* This data is passed in RIL_ExtensionRecord and rec contains this
* structure when type is RIL_UUS_INFO_EXT_REC */
typedef struct {
RIL_UUS_Type uusType; /* UUS Type */
RIL_UUS_DCS uusDcs; /* UUS Data Coding Scheme */
int uusLength; /* Length of UUS Data */
char * uusData; /* UUS Data */
} RIL_UUS_Info;
/* CDMA Signal Information Record as defined in C.S0005 section 3.7.5.5 */
typedef struct {
char isPresent; /* non-zero if signal information record is present */
char signalType; /* as defined 3.7.5.5-1 */
char alertPitch; /* as defined 3.7.5.5-2 */
char signal; /* as defined 3.7.5.5-3, 3.7.5.5-4 or 3.7.5.5-5 */
} RIL_CDMA_SignalInfoRecord;