Note 3 IMEI writing questions

[ecs87]

You're going to need to buy a CERT or: buy a G900H, read the cert and use that to write to your other phones. There are no other choices. I know...it's ****ty.

[ecs87]

Its not really a business of selling it rather than having a way out should one of your associates decide to go rogue and start insurance claims on that IMEI. At least you have enough money to buy another CERT/G900F. There's no use selling it if you can't cover your behind.

[mchizan]

Okay Guys, going through the thread, its a crash program of what i am about to start hacking in, phones.

But my smart friends, i have heard of a guy who can change the imei of G900F using his bare hands, wifi maybe. is that possible,or a dupe?

[smsprepaids]

any body have idea of commands that need to be sent to efs wipe note 4 the partitions are larger than its previous models standard commands not working.

[Haltec]

Your frends are too smart for us.

Please don't inform them about our existance.

[ecs87]

Lol Haltec. Are they going to steal us away from the community, lock us away in a room and force us to patch security holes?!

No one other than probably some Samsung devs can create a CERT from scratch.

How do you know that the old EFS wipe method doesnt work? I'm pretty sure you're experiencing what other users are. You don't just click wipe EFS...most of the time it requires a battery pull beforehand.

[smsprepaids]

U may be right as i may be going at it wrong i did read somewhere about taping a tab on battery maybe it does a voltage bypass. I was usong adb wipe on n3 and s5 i usually don't use a box for the wipe. So are you inferring battery pull before start or... Thanks for reply

[Gambitv01]

i was going to post a link?

[Victor]

Originally Posted by smsprepaids

any body have idea of commands that need to be sent to efs wipe note 4 the partitions are larger than its previous models standard commands not working.

Why need WIPE EFS?

Have another method:

1. Read CPU_ID
2. Read NV_DATA.BIN ... or similar area
3. Decrypt ... do something what you want
4. Crypt back and return to phone

[ecs87]

Originally Posted by Victor

Why need WIPE EFS?

Have another method:

1. Read CPU_ID
2. Read NV_DATA.BIN ... or similar area
3. Decrypt ... do something what you want
4. Crypt back and return to phone

Hi Victor,

You might be a little outdated lol. Qualcomm phones don't seem to use nv_data.bin anymore. The NV data is scattered across three different partitions (maybe now 4 on the Note 4).

[Victor]

Originally Posted by ecs87

Hi Victor,

You might be a little outdated lol. Qualcomm phones don't seem to use nv_data.bin anymore. The NV data is scattered across three different partitions (maybe now 4 on the Note 4).

How you interpret following:

"NV_DATA.BIN ... or similar area"

- excact NV_DATA.BIN file
- "similar area" as same functionality

??????????????????????????????

in broadcomm is not only one file.

imeiitem.bin, prodcode.dat etc.

Latest I reverse XMM6260 and is nv_data.bin

Regards: Victor

[ecs87]

The thing is, we can't decrypt the partitions holding the EFS data. If you even try pulling the EFS data partitions and loading them to another phone, it screws up the EFS and the baseband becomes unknown. This would be a backup from the SAME EXACT PHONE MODEL. You'd think it'd just screw up the EFS; no clue why it "corrupts" the baseband too. Probably because it's memory residing on the same processing chip (CP instead of AP).

[Victor]

Originally Posted by ecs87

The thing is, we can't decrypt the partitions holding the EFS data. If you even try pulling the EFS data partitions and loading them to another phone, it screws up the EFS and the baseband becomes unknown. This would be a backup from the SAME EXACT PHONE MODEL. You'd think it'd just screw up the EFS; no clue why it "corrupts" the baseband too. Probably because it's memory residing on the same processing chip (CP instead of AP).

Things are verry easy. Is named CPU ID. Crypto stuff is linked with cpuid as unique parameter. Ofcourse in wrong cpuid will fall all decryption and baseband recognition will fall.
In broadcomm cpuid is still hard coded in fware, infineon/intel xmms using scuid registers, Qualcomm old is hardcoded new is hardcoded data plus additional crypto.

[ecs87]

Originally Posted by Victor

Things are verry easy. Is named CPU ID. Crypto stuff is linked with cpuid as unique parameter. Ofcourse in wrong cpuid will fall all decryption and baseband recognition will fall.
In broadcomm cpuid is still hard coded in fware, infineon/intel xmms using scuid registers, Qualcomm old is hardcoded new is hardcoded data plus additional crypto.

Easy? This is definitely currently over my head. I assume because I don't have any JTAG experience?

[Victor]

Originally Posted by ecs87

Easy? This is definitely currently over my head. I assume because I don't have any JTAG experience?

No not need jtag experience. After lot of disassembly *.so files from /lib/ folder will see how to read SCU_ID from XMMXXXX family cpus. Broadcomm still using hard coded HW_ID.

This is hard to read ID...

... other is standart cryptography.