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.

[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

[Guide] Patch libandroid_runtime to allow suhide to work. (Pixel/Pixel XL)

This thread is about hiding root. Feel free to discuss anything ranging from MagiskHide to suhide. See the suhide patching instructions below.
Introduction:
With the November security patches, Google back-ported a security feature that allows only a certain whitelist of filesystem sockets to be used.
This is the same feature that prevents suhide from working.
This particular commit is here:
https://android.googlesource.com/pl...8be33b0bedec211708c4525b9d3f3b4effb385c^!/#F0
If you are building CM or AOSP, all you need to do is revert this commit.
However, for binary builds a more direct patching approach is needed.
As I said earlier:
Fenny said:
The basis of my binary patches is to remove the function calls to
Code:
RuntimeAbort(JNIEnv* env, int line, const char* msg)
and remove a later reference to
Code:
gOpenFdTable
that was causing a crash.
Click to expand...
Click to collapse
ARM
Let me get into a bit more detail, and we can start with the error message that zygote spits out with an unpatched version of the file:
"Unable to construct file descriptor table"
We see that in the commit here:
Code:
+ // Close any logging related FDs before we start evaluating the list of
+ // file descriptors.
+ __android_log_close();
+
+ // If this is the first fork for this zygote, create the open FD table.
+ // If it isn't, we just need to check whether the list of open files has
+ // changed (and it shouldn't in the normal case).
+ if (gOpenFdTable == NULL) {
+ gOpenFdTable = FileDescriptorTable::Create();
+ if (gOpenFdTable == NULL) {
+ RuntimeAbort(env, __LINE__, "Unable to construct file descriptor table.");
+ }
+ } else if (!gOpenFdTable->Restat()) {
+ RuntimeAbort(env, __LINE__, "Unable to restat file descriptor table.");
+ }
+
pid_t pid = fork();
When searching for references to the string in the disassembly of the file:
Code:
.text:000C8CC8 ADD R2, PC ; "Unable to construct file descriptor tab"...
.text:000C8CCA B loc_C8CDE
.text:000C8CCC BL sub_C845C
.text:000C8CD0 CBNZ R0, loc_C8CE2
.text:000C8CD2 LDR.W R2, =(aUnableToRestat - 0xC8CE0)
.text:000C8CD6 MOV R0, R4
.text:000C8CD8 MOV.W R1, #0x1D6
.text:000C8CDC ADD R2, PC ; "Unable to restat file descriptor table."
.text:000C8CDE BL sub_C873C
.text:000C8CE2 BLX fork
So, we're looking at the instruction "BL sub_C873C" as "RuntimeAbort" we know it's the right one because it is a conditional call just before the fork.
Which in hex is:
Code:
FF F7 2D FD
The simplest patch is to remove the function call entirely by replacing this with the arm equivalent of nop.
Code:
00 00 00 00
However, that breaks things because the file descriptor variable now contains a null where a reference should be.
Code:
.text:000C8D08 LDR.W R0, [R12]
.text:000C8D0C LDR.W R9, [R0,#8] ; <- Crash happens here.
.text:000C8D10 CMP.W R9, #0
.text:000C8D14 BEQ loc_C8D38
Hex:
Code:
DC F8 00 00 D0 F8 08 90 B9 F1 00 0F
So, since we always need to take the BEQ branch, we're going to replace the whole lot of functions with:
Code:
.text:000C8D08 MOVS R0, #0
.text:000C8D0A MOVS R0, #0
.text:000C8D0C MOVS R0, #0
.text:000C8D0E MOVS R0, #0
.text:000C8D10 MOVS R0, #0
.text:000C8D12 CMP R0, #0
Hex:
Code:
00 20 00 20 00 20 00 20 00 20 00 28
ARM64
The ARM64 patches are the same idea, but different opcodes:
In this example sub_881B8 calls our RuntimeAbort function, so first we nop out the call to that.
Replace:
Code:
.text:000000000014EF8C ADD X2, X27, #[email protected] ; "Socket name not whitelisted : %s (fd=%d"...
.text:000000000014EF90 MOV W4, W20
.text:000000000014EF94 MOV W0, #6
.text:000000000014EF98 MOV X19, #0
[B].text:000000000014EF9C BL sub_881B8[/B]
.text:000000000014EFA0 B loc_14ECA0
Hex:
Code:
87 E4 FC 97
Replace with:
Code:
.text:000000000014EF8C ADD X2, X27, #[email protected] ; "Socket name not whitelisted : %s (fd=%d"...
.text:000000000014EF90 MOV W4, W20
.text:000000000014EF94 MOV W0, #6
.text:000000000014EF98 MOV X19, #0
[B].text:000000000014EF9C NOP[/B]
.text:000000000014EFA0 B loc_14ECA0
Hex:
Code:
1F 20 03 D5
Next, we patch away the crash:
We want to take the CBZ X23, loc_151AC0 jump.
Replace:
Code:
.text:00000000001510CC ADRP X9, #[email protected]
.text:00000000001510D0 LDR X10, [X9,#[email protected]]
[B].text:00000000001510D4 LDR X23, [X10,#0x10][/B]
.text:00000000001510D8 CBZ X23, loc_151AC0
.text:00000000001510DC LDR X19, [X23,#0x18]
.text:00000000001510E0 CBZ X19, loc_1511F4
.text:00000000001510E4 BL sub_88468
.text:00000000001510E8 MOV X22, X0
.text:00000000001510EC ADRP X11, #[email protected] ; "/dev/null"
.text:00000000001510F0 ADD X24, X11, #[email protected] ; "/dev/null"
.text:00000000001510F4 B loc_151174
Hex:
Code:
57 09 40 F9
Replace with:
Code:
.text:00000000001510CC ADRP X9, #[email protected]
.text:00000000001510D0 LDR X10, [X9,#[email protected]]
[B].text:00000000001510D4 MOV X23, #0[/B]
.text:00000000001510D8 CBZ X23, loc_151AC0
.text:00000000001510DC LDR X19, [X23,#0x18]
.text:00000000001510E0 CBZ X19, loc_1511F4
.text:00000000001510E4 BL sub_88468
.text:00000000001510E8 MOV X22, X0
.text:00000000001510EC ADRP X11, #[email protected] ; "/dev/null"
.text:00000000001510F0 ADD X24, X11, #[email protected] ; "/dev/null"
.text:00000000001510F4 B loc_151174
Hex:
Code:
17 00 80 D2
Finally, nop out the second call to RuntimeAbort (ARM optimized these two calls into one, whereas arm64 split them into two subfunctions.)
Replace:
Code:
.text:0000000000151AAC MOV X0, X25
.text:0000000000151AB0 MOV W1, #0x1D3
.text:0000000000151AB4 ADD X2, X4, #[email protected] ; "Unable to construct file descriptor tab"...
[B].text:0000000000151AB8 BL sub_150264[/B]
.text:0000000000151ABC B loc_150F10
Hex:
Code:
EB F9 FF 97
Replace with:
Code:
.text:0000000000151AAC MOV X0, X25
.text:0000000000151AB0 MOV W1, #0x1D3
.text:0000000000151AB4 ADD X2, X4, #[email protected] ; "Unable to construct file descriptor tab"...
[B].text:0000000000151AB8 NOP[/B]
.text:0000000000151ABC B loc_150F10
Code:
1F 20 03 D5
TL;DR
I have this working on 7.1/7.1.1.
The gist:
Patching ART binaries required. System modification required. (can't bind mount modified ART or suhide breaks).
Known issues:
UI prompts to allow new or updated root apps do not display when suhide is enabled. (7.1.1+)
SuperSU 2.79 SR1 and above use incompatible selinux contexts with Suhide 0.55 and below.
JAYNO20 said:
I can confirm this works on the 5" Pixel device as well. This is NOT limited to just the XL.
Click to expand...
Click to collapse
Downloads:
Here are a couple patched versions:
libandroid_runtime_pixelxl_NDE63V.tar
libandroid_runtime_pixelxl_NMF26O.tar
libandroid_runtime_pixelxl_NMF26Q.tar
libandroid_runtime_pixelxl_NOF26V.tar (Reported working with NOF27B/C, N2G47E/J/K)
You WILL need to match your builds up.

Finally!
Cant wait for the write up!

ghostENVY said:
Finally!
Cant wait for the write up!
Click to expand...
Click to collapse
Well, since you can't wait... I will do a full write-up when I get home, until then, you can grab the modded Android runtime files from NDE63V: libandroid_runtime_pixelxl_NDE63V.tar
Basic process is: Replace modded files in system, fix permissions, flash suhide.

Will this work on NMF26Q?

Also, NMF26O?

Ker~Man said:
Will this work on NMF26Q?
Click to expand...
Click to collapse
JAYNO20 said:
Also, NMF26O?
Click to expand...
Click to collapse
ART libs look like they can be patched for both of those builds, but I haven't done them yet.
The old libs I posted probably won't set your phone on fire, but it is very likely you would have weird issues even if it doesn't just bootloop, which is what I would expect to happen.

JAYNO20 said:
Also, NMF26O?
Click to expand...
Click to collapse
So, after replacing the first of the four files, my phone froze immediately and now boots to an all black screen. Just fu**ing great...
Any ideas other than a full flash of stock???

Fenny said:
ART libs look like they can be patched for both of those builds, but I haven't done them yet.
The old libs I posted probably won't set your phone on fire, but it is very likely you would have weird issues even if it doesn't just bootloop, which is what I would expect to happen.
Click to expand...
Click to collapse
Any chance you'll get around to patching those as well?

JAYNO20 said:
Any chance you'll get around to patching those as well?
Click to expand...
Click to collapse
+1. Would be really nice...

Ker~Man said:
+1. Would be really nice...
Click to expand...
Click to collapse
I'd love to be able to use Android Pay again...

Ker~Man said:
So, after replacing the first of the four files, my phone froze immediately and now boots to an all black screen. Just fu**ing great...
Any ideas other than a full flash of stock???
Click to expand...
Click to collapse
Yeah, you're not going to be able to replace those files while you're booted into the normal system.
If you have a backup of the file restore it in recovery. If not, you'll probably need to flash a stock system partition.
It is likely that you did not get a chance to set permissions on the file when you replaced it. You can try going into recovery and try setting the correct owner and permissions on the file.

I'm so looking forward to this write up, thank you for your work!

Great job!

The anticipation is killing me

MyNarwhalBacon said:
The anticipation is killing me
Click to expand...
Click to collapse
Likewise!

Added some patched versions to the OP.
Write-up still pending. Working on an auto patcher for the files.

Fenny said:
Added some patched versions to the OP.
Write-up still pending. Working on an auto patcher for the files.
Click to expand...
Click to collapse
Nice work. Will the Q files work with the O update?
---------- Post added at 02:47 AM ---------- Previous post was at 02:34 AM ----------
Also, will this be ok to flash to the Pixel? (NOT XL)

Hi, great work. Is it doable for other brands (Sammy, Moto, Huawei...)? Any advice, paths to follow? Thx
Echoe™ team member / S7E

I tried on O update, bootloops.

You sir are the man. I'm excited to be able to root and still play Pokemon go

Adding LTE / 4G bands on gt-i9295

Hi guys!
Does anybody know if it's possible to add bands 2,4,7,28 on the gt-i9295 phone?
I've reading about the NV calculator, putting the phone in modem debug mode, the *#011# codes, etc, but I was hopping to find someone who did this successfully on this phone and who could assist me on the process.
Thanks!

I've successfully followed some mixed tutorials and got a .QCN dump of the NV memory of my gt-i9295.
· Went back from Lineage 16 to stock rom using ODIN, following these tutorials for S4 (normal one) and Tab 4
· Since I couldn't find the firmware for i9295 on sammobile web, I looked for it on youtube (don't remember exactly which video, but something like https://www.youtube.com/watch?v=SW_QF0ZdhEU that took me to mega.nz). The firmware was in Russian and had to change it on the first startup.
· Once in the stock rom, I've followed this tutorial, with the recommendations from "mrrocketdog" on page 146 for adding "cp logging" from recovery and "*#9090# into option 2 with * around it. reboots automatically". Also reviewed these:
- https://galaxys4root.com/galaxy-s4-...aws-bands-on-att-galaxy-s4-sgh-i337sgh-i337m/
- https://forum.xda-developers.com/galaxy-s5/general/guide-enable-unlock-edit-add-gsm-lte-t2948822
- https://forum.xda-developers.com/galaxy-s5/general/how-to-add-rf-lte-frequency-bands-to-t2886059
- https://forum.xda-developers.com/android/general/3g-lte-frequency-nv-items-qualcomm-t2950491
- https://forum.xda-developers.com/android/apps-games/app-qualcomm-nv-calculator-adding-2g-3g-t2915649
- https://forum.xda-developers.com/hardware-hacking/hardware/how-to-correct-edit-qcn-files-t3850464
Now I have my QCN file using QPST but I cannot find NV 06828 and NV 06829 registres in my file and I'm stuck on that part.
These are the files:
i9295.qcn and i9295.txt version
I need to add 4G bands for Argentina (https://www.kimovil.com/es/frequency-checker/AR)
B2 – 1900 MHz
B4 – 1700 MHz AWS (most important)
B7 – 2600 MHz
B8 – 900 MHz
B28 – 700 MHz APT (important too) (B17 on same freq does not work)
Does anyone know how to edit my QCN file to add those bands?
Thanks!

hello
you have not a full backup of qcn ( maybe you don't us the right QPST version for this device )
original QCN for I9295 :
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
so : D5 00 08 flipped = B 1,3,5,7,8,and 20
i need some free time to calculate and look all NV that you must add for trying
regards

yakapa40 said:
original QCN for I9295 :
Click to expand...
Click to collapse
Do you have this file for download?
"GT-I9295_M9615A-CEFWTAZM-4.0.17083_28-9-2014_16-37-34.qcn"
Thanks!
Ignacio

I9295 qcn link :
https://mega.nz/#!zPwx2QaT!ZF9TBl06POoD8hja9WUBgVKGEq2xLE9wE4eSIP0GBsk
take care only for control , you must not flash it on your device
your qcn is unique
there is always one qcn file for each device ( IMEI S/N product date product code original CSC .... efs ....)

Thanks! I've installed QPST build 411 and got the full QCN file (there are too many diffs with the file you've linked, I can upload a .patch file if needed to review them)
So, in order to add these bands:
B2 – 1900 MHz
B4 – 1700 MHz AWS (most important)
B28 – 700 MHz APT (important too) (B17 on same freq does not work)
i need to change the "D5 00 08 00" part like this:
Code:
1101 0101 0000 0000 0000 1000 0000 0000‬ = D5 00 08 00 (original)
0000 0000 0000 1000 0000 0000 1101 0101 = 00 08 00 D5 (flipped)
3332 2222 2222 2111 1111 1100 0000 0000 (tens)
2109 8765 4321 0987 6543 2109 8765 4321 (units)
· ·· · · · (original: 1,3,5,7,8,20)
* · ·· · *·*· (| bands 2,4,28)
0000 1000 0000 1000 0000 0000 1101 1111 (final: 1,2,3,4,5,7,8,20,28)
0 8 0 8 0 0 D F = 08 08 00 DF
flipped: DF 00 08 08
Is this calculation right?
Should I take some extra backup steps (other than having the .qcn file for restore)?
Thanks!

exact for NV6828 :
i think you also need to add configuration for these bands
exemple for B4 :
https://drive.google.com/file/d/1MsPBiHRIw9l_8W66BVPJlfwV36sQGU9X/view?usp=sharing

<duplicated>

@yakapa40
So, I did run "Restore" with the QCN file edited using "DF 00 08 08" instead of "D5 00 08 00" which was exactly located in address "0100AC1A" as described in this video (using a hex editor):
(jump to minute 4:10)
https://youtu.be/jPouF3bzoDI?t=250
The QCN file was restored successfully and the phone restarted automatically (as described in here)
But I'm still unable to join 4G networks in any of the 3 provider networks.
I don't know how to set those configurations for B4 that you shared. Can you point me with a procedure?
Thanks!

"Rooted LG G6 Device Owners" - Please post file names of the archive you downloaded from LG to unlock your bootloader

I am trying to check whether LG are still publicly hosting G6 bootloader unlock files online. I know you probably think but wait, we know they don't. That may not be the case.
The server may still be publicly hosting the files which device owners need to unlock their bootloaders, by reverse engineering the cached page data from the internet archives I have extracted a download link from the page.
Code:
"https://developer.lge.com/resource/mobile/common/file/DownloadFile.dev" + "?fileId=" + encodeURIComponent( json.fileId ) ;
Which appears to be missing the encoded file name. If we could get enough file names and they are indeed still publicly hosted online, we could possibly download our bootloader unlock files directly from source if we can establish a pattern in the data.
I am guessing that these file names will be in someway related to the device identifier. It's a long shot but I am willing to check it out, please help by posting the file name of the archive you extracted your unlock.bin file from this is possibly a ZIP archive you downloaded from LG website to unlock your bootloader and the file name of unlock.bin if different from unlock.bin.

Hi,
Here are the informations of an old device I owned but dead today. So it's OK to use them.
- IMEI or MEID: 356144087429995- Device ID: 662CDCF3D09A5AED38E08DB652EC4CC6F63B24DADB2332BC0C7CD30A9924D731

Jeff_i said:
Hi,
Here are the informations of an old device I owned but dead today. So it's OK to use them.
- IMEI or MEID:356144087429995- Device ID:662CDCF3D09A5AED38E08DB652EC4CC6F63B24DADB2332BC0C7CD30A9924D731
Click to expand...
Click to collapse
So it looks like the file indeed is named unlock.bin, i dont think anybody is renaming it from original name to unlock.bin
Was the file downloaded from LG in zipped format and you had unzipped it? OP would like to know the name of the original file received directly from LG if it was zipped and not as you have uploaded it here on the forum.

Right !
The attached file from lg was directly the unlock.bin file and I used it as is.

Any news?

Would there be any way to decode and re encode the unlock.bin file to use the IMEI and Device ID of your own phone?

Here are a few unlock files (from old G6 (and a G5)

Any updates ?

Please update on new ways to generate the unlock.bin. I've got an LG Stylus 2 Plus K530F and it's crazy impossible now that LG took down the site.

"Wrong Bootloader Unlock key" is what I get unfortunately

Hello,
I've take a look at the unlock.bin files shared here and this is what I've discovered:
1. when you upload the unlock.bin file, it must exactly be 1024 bytes, any other file size will give you back an error.
2. it's a null (00) padded file
3. the unlock file seems to always begin with this sequence of 20 bytes: 159e 8db7 d36b 2d7e 0001 0000 0002 0000 0100 0000
4. LG G6) contains 2 blocks of 256 bytes separated by 12 null bytes: 0000 0000 0000 0000 0000 0000
So the G6 structure seems to always be (in bytes):
20 (initial sequence) + 256 (first part) + 12 (null bytes) + 256 (second part) + 480 (padding)
4b. LG G5) after the same initial sequence (159e 8db7 d36b 2d7e 0001 0000 0002 0000 0100 0000) there is just one "block" of 256 bytes before the null padding.
Final thoughts:
I may guess that decrypting the file itself is impossible and probably the unlock keys must be extracted separately (could be as simple as):
$ head -c 276 unlock.bin | tail -c 256 > key1.bin
and (only on G6):
$ tail -c 736 unlock.bin | head -c 256 > key2.bin
If someone could share more binary files downloaded from the LG website (also for other devices) it may be useful to do more guessing about the way this files was built.
--EDIT 1
I found a post with a link to this repository:
lk/platform/lge_shared at master · jaehyek/lk
Contribute to jaehyek/lk development by creating an account on GitHub.
github.com
This made me figure how the previous models (including G5?) unlock.bin file was generated and read.
According to lge_verified_boot.c, the input structure (unlock_input_data_type) is obtained by concatenating device_id and imei taken from the phone.
All what validation (verify_image) does is comparing sha256 of it with the decoded part of unlock.bin content.
So, unlock.bin's "key1" should be obtained with: encrypt( sha256( concat( device_id, imei ) ) )
The good news is that the repository includes a "keys" folder with all the keystores used... The bad one is that I haven't found the "d2i_LGE_KEYSTORE" function that knows how to read them.
I tried again with the strategy of comparing files and discovered that there are some recurring patterns in keystores:
they seems to start with: 0x30, 0x82, 0x01
then contains some bits that identify the keystore, then:
0x30, 0x82, 0x01, 0x1f, 0x30, 0x82, 0x01, 0x1b, 0x30, 0x0b, 0x06, 0x09,
0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x0b, 0x30, 0x82, 0x01,
0x0a, 0x02, 0x82, 0x01, 0x01, 0x00
finally, sequence ends with: 0x02, 0x03, 0x01, 0x00, 0x01.
I will write here again if I can find the public key, in order to decode the posted unlock.bin files and to collect feedback of whom posted them without imeis and device ids.
I just may need the sha256 sums of the 2 concatenated strings.
--EDIT 2
After writing a simple C program to print the Keystore inside bl_unlock.c (BLUNLOCK_KEYSTORE variable), I obtained a binary file that can be read using:
$ openssl asn1parse -in keystore -inform DER -i
0:d=0 hl=4 l= 309 cons: SEQUENCE
4:d=1 hl=2 l= 1 prim: INTEGER :00
7:d=1 hl=2 l= 13 prim: PRINTABLESTRING :UNLOCK_RSA_02
22:d=1 hl=4 l= 287 cons: SEQUENCE
26:d=2 hl=4 l= 283 cons: SEQUENCE
30:d=3 hl=2 l= 11 cons: SEQUENCE
32:d=4 hl=2 l= 9 prim: OBJECT :sha256WithRSAEncryption
43:d=3 hl=4 l= 266 cons: SEQUENCE
47:d=4 hl=4 l= 257 prim: INTEGER :92D5E3A2C6F311A1FD325C94415DF197BA1C2B307C1EDBB5D9ED109AB8A639F10D61F6582B367AAECBBF95A130E54754667565AA6A60AFA6ADD6F246048C839D017D21849F5AA2A08FA5DBDE0712694E7E80FC42A709CEE3A91A5B11873A079E0FB04E14001C6B5BB4A5DDF52E793A8D5DD4E177C560C7CEDFB8FCC844B6640B4813D629AB9B34CFD5081C5A5384225049FE0B62EFBF79728421360D3C874B387CE5B67891F8942DB431BEAAC7414ED52AFA283EA39EAD160DA51FD7F8393BAF6BBCA780DFAC477BFEF43C61E9431B85F70E4DB2CF7B0F7A410DB24D6F806C91A2C650897E9B90668D25B0A9174054E133B4382ADA5AEC3527D2F4CABE263917
308:d=4 hl=2 l= 3 prim: INTEGER :010001
--EDIT 3
First of all, I want to say that I've downloaded an OTA update of LG G6 and this can probably confirm that this keystore is still there:
LG-H87010f-Flashable.Bootloader.zip
extract and:
$ grep "UNLOCK_RSA_02" -R
grep: bootloader/aboot.img: Binary file matches
so I invested more time on it figuring how the keystore originated and found this source code of KeystoreSigner that produce the same DER sequence:
verity/KeystoreSigner.java - platform/system/extras - Git at Google
so I wrote a small Java program to print the public key in PEM format:
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAktXjosbzEaH9MlyUQV3xl7ocKzB8Htu
12e0QmrimOfENYfZYKzZ6rsu/laEw5UdUZnVlqmpgr6at1vJGBIyDnQF9IYSfWqKgj6Xb3gcSaU
5+gPxCpwnO46kaWxGHOgeeD7BOFAAca1u0pd31Lnk6jV3U4XfFYMfO37j8yES2ZAtIE9Ypq5s0z
9UIHFpThCJQSf4LYu+/eXKEITYNPIdLOHzltniR+JQttDG+qsdBTtUq+ig+o56tFg2lH9f4OTuv
a7yngN+sR3v+9Dxh6UMbhfcOTbLPew96QQ2yTW+AbJGixlCJfpuQZo0lsKkXQFThM7Q4Ktpa7DU
n0vTKviY5FwIDAQAB
-----END PUBLIC KEY-----
It is a 2048-bit RSA public key, that I'm still not able to use to read the unlock files posted yet, but I share all my work just in case anybody wants to help.
-- EDIT 4
This is how I'm trying to use all the pieces I've put together. It's working now!!!
Now we have a working method to validate unlock.bin files for older phones!!!
--EDIT 5
Updated code with the working version.
-- EDIT 6
With a big thank to @ncrt that figured how the second signature is generated we now know how to completely validate the unlock.bin of G6.
This is the final version of the Java validator:
Java:
import java.io.File;
import java.math.BigInteger;
import java.nio.file.Files;
import java.security.KeyFactory;
import java.security.MessageDigest;
import java.security.PublicKey;
import java.security.Signature;
import java.security.spec.RSAPublicKeySpec;
class Main {
private static final int UNLOCK_BIN_SIZE = 1024;
private static final int UINT32_T_SIZE = 4;
private static final int SIGNATURE_SIZE = 512;
private static final int KEY_SIZE = 256;
private static final int EXTRA_SIZE = 492;
private static final long SECURITY_UNLOCK_MAGIC1 = 2377586078L; // 0x8DB7159E
private static final long SECURITY_UNLOCK_MAGIC2 = 763286379L; // 0x2D7ED36B
private static final long SECURITY_UNLOCK_VERSION = 1L;
private static final int IMEI_SIZE = 32;
private static final int DEVICE_ID_SIZE = 96;
// RSA_UNLOCK_02
private static final RSAPublicKeySpec spec = new RSAPublicKeySpec(new BigInteger(
"18536265221834400955526124823946945144241534366405270883862606828214326557303158761374427696439760867810300046710668389940627901357786930619155280232713255180467267693281615312585736047834931276426122242381388755141769507773314618374615964530031495500324126445550145922318729183762394336526893965841523887301431217744349619177044755418369600023019646764547203434859153096499560007159303235140562773302106895748271986503337696246115511449909141742149128001718847058167094531480513164043443149146227140700654562659385941009377485565173992175722386093166833729231966326215327030617445434971297334403421561820089441204503"),
new BigInteger("65537"));
public static void main(String[] args) throws Exception {
String imei = "356144087429995";
String deviceId = "662CDCF3D09A5AED38E08DB652EC4CC6F63B24DADB2332BC0C7CD30A9924D731";
byte[] fileContent = Files.readAllBytes(new File("unlock.bin").toPath());
if (fileContent.length != UNLOCK_BIN_SIZE) {
System.err.println("Filecontent: " + fileContent.length + " expected: " + UNLOCK_BIN_SIZE);
return;
}
int offset = 0;
byte[] magic1 = new byte[UINT32_T_SIZE];
System.arraycopy(fileContent, offset, magic1, 0, UINT32_T_SIZE);
offset += UINT32_T_SIZE;
byte[] magic2 = new byte[UINT32_T_SIZE];
System.arraycopy(fileContent, offset, magic2, 0, UINT32_T_SIZE);
offset += UINT32_T_SIZE;
byte[] version = new byte[UINT32_T_SIZE];
System.arraycopy(fileContent, offset, version, 0, UINT32_T_SIZE);
offset += UINT32_T_SIZE;
byte[] hash_type = new byte[UINT32_T_SIZE];
System.arraycopy(fileContent, offset, hash_type, 0, UINT32_T_SIZE);
offset += UINT32_T_SIZE;
byte[] key_size = new byte[UINT32_T_SIZE];
System.arraycopy(fileContent, offset, key_size, 0, UINT32_T_SIZE);
offset += UINT32_T_SIZE;
if (deserialize_uint32(magic1) != SECURITY_UNLOCK_MAGIC1 || deserialize_uint32(magic2) != SECURITY_UNLOCK_MAGIC2
|| deserialize_uint32(version) != SECURITY_UNLOCK_VERSION) {
System.err.println("Magic numbers not found");
return;
}
byte[] signature = new byte[SIGNATURE_SIZE];
System.arraycopy(fileContent, offset, signature, 0, SIGNATURE_SIZE);
offset += SIGNATURE_SIZE;
byte[] extra = new byte[EXTRA_SIZE];
System.arraycopy(fileContent, offset, extra, 0, EXTRA_SIZE);
offset += EXTRA_SIZE;
byte[] input = new byte[DEVICE_ID_SIZE + IMEI_SIZE];
System.arraycopy(deviceId.getBytes(), 0, input, 0, deviceId.length());
System.arraycopy(imei.getBytes(), 0, input, DEVICE_ID_SIZE, imei.length());
final KeyFactory f = KeyFactory.getInstance("RSA");
final PublicKey publicKey = f.generatePublic(spec);
byte[] firstSignature = new byte[KEY_SIZE];
System.arraycopy(signature, 0, firstSignature, 0, KEY_SIZE);
Signature firstSignatureVerify = Signature.getInstance("NonewithRSA");
firstSignatureVerify.initVerify(publicKey);
firstSignatureVerify.update(MessageDigest.getInstance("SHA-256").digest(input));
boolean sigVerified = firstSignatureVerify.verify(firstSignature);
System.out.println("First signature verified: " + sigVerified);
byte[] secondSignature = new byte[KEY_SIZE];
System.arraycopy(signature, KEY_SIZE + 12, secondSignature, 0, KEY_SIZE - 12);
System.arraycopy(extra, 0, secondSignature, KEY_SIZE - 12, 12);
Signature secondSignatureVerify = Signature.getInstance("SHA256withRSA");
secondSignatureVerify.initVerify(publicKey);
secondSignatureVerify.update(input);
boolean sig2Verified = secondSignatureVerify.verify(secondSignature);
System.out.println("Second signature verified: " + sig2Verified);
}
private static long deserialize_uint32(byte[] b) {
long l = (long) b[0] & 0xFF;
l += ((long) b[1] & 0xFF) << 8;
l += ((long) b[2] & 0xFF) << 16;
l += ((long) b[3] & 0xFF) << 24;
return l;
}
}
Cheers
Francians

hope is fine to reserve more room....
RESERVED

francians said:
First of all, I want to say that I've downloaded an OTA update of LG G6 and this can probably confirm that this keystore is still there
Click to expand...
Click to collapse
is this at all helpful to you, or no?
LG Open Source
opensource.lge.com

francians said:
hope is fine to reserve more room....
RESERVED
Click to expand...
Click to collapse
How can I unlock my phone whit this little program?

francians said:
--EDIT 5
Updated code with the working version.
Cheers
How can I unlock my phone whit this little program?
Click to expand...
Click to collapse

That code demonstrates how the unlock works and cannot generate a file to unlock your phone. For G6 the puzzle is still uncompleted, but I am working on it. If there will be a method to unlock I'll write a dedicated post and give you a compiled software

Honkette1738 said:
is this at all helpful to you, or no?
LG Open Source
opensource.lge.com
Click to expand...
Click to collapse
The OTA will be helpful to reverse engineering it, since the source I've found is older

I was writing to the german CEO a while ago , he said no.
But maybe if we are more and write to Korea , we may have succses ?
Thats what he said :
Dear Mr W,
I have to pass. LG has not been selling cell phones for some time now and the developer services were discontinued at the end of 2021. Unfortunately, it is no longer possible to comply with your request.
For any inquiries, I'm willing to help.
.....

Definitely could be a good idea to ask them to share the private keys since without them it's currently impossible to write an unlock files generator. They may rise security concerns if such keys have been used for something else too.
marcus67 said:
I was writing to the german CEO a while ago , he said no.
But maybe if we are more and write to Korea , we may have succses ?
Thats what he said :
Dear Mr W,
I have to pass. LG has not been selling cell phones for some time now and the developer services were discontinued at the end of 2021. Unfortunately, it is no longer possible to comply with your request.
For any inquiries, I'm willing to help.
.....
Click to expand...
Click to collapse

francians said:
Definitely could be a good idea to ask them to share the private keys since without them it's currently impossible to write an unlock files generator.
Click to expand...
Click to collapse
could that be in engineering bootloaders, or likely not?