[DEV][THE S-OFF CAMPAIGN] We need electrical engineers & experts in JTAG, OpenOCD!

Search This thread

no.human.being

Senior Member
Oct 29, 2011
981
987
When i tried 2nd time... it said.....

incorrect base signature...........

Am i S-OFF with showing status "S-ON"?

No, when it claims "incorrect base signature", it didn't find an HBOOT image on the "mtd7". It only patched the HBOOT when it claimed "[ OK ] Done!" in the end.

thx. @nhb: please check if it is patched :)

edit: downloaded it. doesn't look like a hboot at all o_O

No. Sure it would abort when it would see that. No chance it got patched.
 
  • Like
Reactions: MrTaco505

no.human.being

Senior Member
Oct 29, 2011
981
987
Your cammand gave me this file....
Is it not the right thing you want??????

Did the exploit report "Success!" or did it report "[ERROR]"? I'm sure it did report "[ERROR]" and did not patch provided you let it run on the same memory (same device provided as parameter and same mapping provided to the kernel). It doesn't look like HBOOT at all. HBOOT starts with a quite "individual" 32-bit word followed by lots of version strings and these are all checked by the exploit before it patches anything.
 
  • Like
Reactions: MrTaco505
Sep 24, 2011
48
12
Kotkapura
No, probably not. But according to how your hboot looks like I'm wondering your phone still works :D

My phone is working very good...... As usual....
I think there is mistake in typing command that you told me.....
Is that was the right file u want?????
that i uploaded????

---------- Post added at 08:59 AM ---------- Previous post was at 08:57 AM ----------

Did the exploit report "Success!" or did it report "[ERROR]"? I'm sure it did report "[ERROR]" and did not patch provided you let it run on the same memory (same device provided as parameter and same mapping provided to the kernel). It doesn't look like HBOOT at all. HBOOT starts with a quite "individual" 32-bit word followed by lots of version strings and these are all checked by the exploit before it patches anything.

In my First Try... (Approximate, not pure remember)......
It said....
Reading....
Patching hboot....
PAtched successfully....
Done..... (like it)...
I thought i patched successfully...
Bt i restarted....
It still S-ON......
No luck...
 

mobilescooby

Senior Member
Oct 7, 2010
213
10
Cork
have checked and double checked every step 5 times. i simply cannot get this script to patch the hboot :(

[ LOG ] Step 1: Reading from mtd ...
[ LOG ] Step 2: HBOOT analysis ...
[ LOG ] Incorrect base signature for HBOOT-1.08.0099
[ LOG ] Incorrect base signature for HBOOT-1.09.0099

[ERROR] Failed to detect HBOOT!

HBOOT-1.08.0099
MICROP-0451
RADIO-7.53.39.03M
Nov 28 2011,19:09:21
 
Sep 24, 2011
48
12
Kotkapura
have checked and double checked every step 5 times. i simply cannot get this script to patch the hboot :(

[ LOG ] Step 1: Reading from mtd ...
[ LOG ] Step 2: HBOOT analysis ...
[ LOG ] Incorrect base signature for HBOOT-1.08.0099
[ LOG ] Incorrect base signature for HBOOT-1.09.0099

[ERROR] Failed to detect HBOOT!

HBOOT-1.08.0099
MICROP-0451
RADIO-7.53.39.03M
Nov 28 2011,19:09:21

@nhb...
After the Pure Success.....
Mine is showing same...
 

theq86

Senior Member
Jan 6, 2009
927
717
37
Nuremberg
Nothing Phone 2
have checked and double checked every step 5 times. i simply cannot get this script to patch the hboot :(

[ LOG ] Step 1: Reading from mtd ...
[ LOG ] Step 2: HBOOT analysis ...
[ LOG ] Incorrect base signature for HBOOT-1.08.0099
[ LOG ] Incorrect base signature for HBOOT-1.09.0099

[ERROR] Failed to detect HBOOT!

HBOOT-1.08.0099
MICROP-0451
RADIO-7.53.39.03M
Nov 28 2011,19:09:21
can you please also provide us with your hboot dump?

instead of inject command type:
Code:
dump_image hboot /sdcard/hboot.img
 
  • Like
Reactions: no.human.being

no.human.being

Senior Member
Oct 29, 2011
981
987
Ok, I've done it on my own phone.

Code:
[ LOG ] Step 1: Reading from mtd ...
[ LOG ] Step 2: HBOOT analysis ...
[ LOG ] Incorrect version string for HBOOT-1.09.0099

[ LOG ] HBOOT-1.08.0099 detected.
[ LOG ] Step 3: Patching ...
[ LOG ] Step 4: NAND unlocking ...
[DEBUG] ./mtdutils/flash_unlock /dev/mtd/mtd7
[ LOG ] Step 5: NAND erasure ...
[DEBUG] ./mtdutils/flash_erase -q -u 0 0 /dev/mtd/mtd7
[ LOG ] Step 6: Writeback ...
[ OK  ] Done!

So the exploit gets through, but the phone is still S-ON. So it's probably not the right thing to patch, but at least it doesn't seem to do any harm to HBOOT either. :D
 

theq86

Senior Member
Jan 6, 2009
927
717
37
Nuremberg
Nothing Phone 2
Ok, I've done it on my own phone.

Code:
[ LOG ] Step 1: Reading from mtd ...
[ LOG ] Step 2: HBOOT analysis ...
[ LOG ] Incorrect version string for HBOOT-1.09.0099

[ LOG ] HBOOT-1.08.0099 detected.
[ LOG ] Step 3: Patching ...
[ LOG ] Step 4: NAND unlocking ...
[DEBUG] ./mtdutils/flash_unlock /dev/mtd/mtd7
[ LOG ] Step 5: NAND erasure ...
[DEBUG] ./mtdutils/flash_erase -q -u 0 0 /dev/mtd/mtd7
[ LOG ] Step 6: Writeback ...
[ OK  ] Done!
So the exploit gets through, but the phone is still S-ON. So it's probably not the right thing to patch, but at least it doesn't seem to do any harm to HBOOT either. :D

please dump and be sure hboot got patched and is no "working garbage"

I find it strange that gauravjuneja01 device still works :D
 
Sep 24, 2011
48
12
Kotkapura
Ok, I've done it on my own phone.

Code:
[ LOG ] Step 1: Reading from mtd ...
[ LOG ] Step 2: HBOOT analysis ...
[ LOG ] Incorrect version string for HBOOT-1.09.0099

[ LOG ] HBOOT-1.08.0099 detected.
[ LOG ] Step 3: Patching ...
[ LOG ] Step 4: NAND unlocking ...
[DEBUG] ./mtdutils/flash_unlock /dev/mtd/mtd7
[ LOG ] Step 5: NAND erasure ...
[DEBUG] ./mtdutils/flash_erase -q -u 0 0 /dev/mtd/mtd7
[ LOG ] Step 6: Writeback ...
[ OK  ] Done!

So the exploit gets through, but the phone is still S-ON. So it's probably not the right thing to patch, but at least it doesn't seem to do any harm to HBOOT either. :D

Now what is the status buddy????????
Will we get S-OFF???
One thing sure that our device will not be bricked.....
 

theq86

Senior Member
Jan 6, 2009
927
717
37
Nuremberg
Nothing Phone 2
okay, both of you guys hboots are md5: 53368ced64bc511f8cd1a0c74cdd193e

I think this "garbage" - and it obviously WORKS is the exotic variation of HBOOT.

So no wonder that the exploit did not want to patch. But their hboots are identical.
 

theq86

Senior Member
Jan 6, 2009
927
717
37
Nuremberg
Nothing Phone 2
That means you and mobilescooby both have the exact same hboot. (actually logical, because your versions are the same)

BUT:

Your versions do not "look" like a normal HBOOT in binary view mode.
 

no.human.being

Senior Member
Oct 29, 2011
981
987
My HBOOT is untouched. I'd say the kernel's mtd drivers pretend to be erasing and writing when in reality they're not. When I do it to an image file (say on the SD card) instead of the device file, it gets patched exactly as I'd expect, but the mtd is not touched.

It's a kernel problem. The exploit is doing it all right, but the kernel is cheating us. So we'll need a custom kernel. Either true Linux (would be the best) or Android built from source with the "security" restrictions removed.

And no it can't be mtdutils problem as if mtdutils didn't erase but kernel did write, the phone would be dead now. Writing to NAND without erasing first leaves nothing but total garbage in the memory. :D

So now I'd say we're definitely stuck at a kernel level problem and that's where most of my skills end.
 

theq86

Senior Member
Jan 6, 2009
927
717
37
Nuremberg
Nothing Phone 2
That's poor :/
I'm not familiar with kernel development, either. it's a chapter on it's own

---------- Post added at 04:54 AM ---------- Previous post was at 04:52 AM ----------

Okay, for you guys a conclusion:

* None of your hboots got patched
* Nothing on your hboots was changed
* You are still S-On
 
  • Like
Reactions: no.human.being

no.human.being

Senior Member
Oct 29, 2011
981
987
But you come to the same conclusion right?

Dump the HBOOT to SD, then run "./inject --disengage-the-safety /sdcard/hboot.img" and it'll patch just fine.

What it does internally is fopen(..., "rb") the device, fread(...) it completely into a buffer in memory, fclose(...) the device again, analyze the buffer to make sure it's what we expect, then patch the buffer in memory, "flash_unlock ..." the device, "flash_erase ..." the device, then fopen(..., "wb") the device again and fwrite(...) the buffer back, then fflush(...) and fclose(...) the device.

So when it claims that everything went right (the calls didn't return failure values) then it'll say "[ OK ] Done!", otherwise it will throw some "[ERROR] ...". So obviously all the calls succeed, but the kernel just "pretends", and in reality does nothing.
 
Last edited:

Top Liked Posts