yashsingh1/xdaforums huggingface dataset:
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Well, in reviewing the results of the various tests, it seems that the format of my rom .tar is not correct.

I need to verify the packing procedure, so I plan to take the stock OC4 kernel, unpack it, repack it & flash.

I'll do that until I can get it to flash ok ... it should be low risk since the OC4 kernel can be flashed with stock Odin.

Once the packing is certain, then we'll be ready to test my rooted rom with both stock & patched Odin.
[AT&T Samsung Galaxy S 5] wforider:
Hoping this is progress
[AT&T Samsung Galaxy S 5] wforider:
Is anyone else getting through kingroot with the success of root and seeing the same thing
[AT&T Samsung Galaxy S 5] UsandThem:
Link to your Kingroot apk? Would like to try :p
[AT&T Samsung Galaxy S 5] anhminhvip:
FAILE when root my phone

S5 active G870A OF3 5.0 :(

Kingroot 5.0.1

plz help me
[AT&T Samsung Galaxy S 5] DejaVuAgain:
DVA_X_G900A_ROM_Alpha3 ready for testing ...

Hello testers ...

After much testing & some risk to my root, I think I finally have a valid Odin flashable file now.

The test package here

includes 3 versions of Odin as well as the rom.

Try the stock Odin 3.11.1 first, followed the v3.12.3 versions.

Please let me know what happens in each case.

The details will dictate the next step ...

(I have the expectation that we're not too far away from being able to load a system image. While that will be nicely stripped down, it will probably not have root ... I'm pretty sure that I'll also need to flash at least the init.d folder, if not more).
[AT&T Samsung Galaxy S 5] boyhonda5:
I tried all three versions of Odin, and all met with the same "md5 error! Binary is invalid" message.
[AT&T Samsung Galaxy S 5] DejaVuAgain:
That's strange ... I had it pass MD5

Please rename the files to .tar ... simply remove the .MD5 extension, & then try again.
[AT&T Samsung Galaxy S 5] wforider:
Can you give the following info from phone info on play store
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Thanks guys ...

I should have reiterated that you probably need to be on the OC4 kernel.

I don't think the system image which is based on OF3 will run on the OI5 kernel.

On the other hand, the resulting error message will be interesting.

The Alpha3 test is primarily to confirm the validity of the build process.

It would be a wonderful surprise if it actually ran.

I'm hoping that once I build a valid system image, that Odin chokes on it rather than the kernel.

Odin should be relatively easy to defeat.

(The S7 people are pushing images onto their devices with a patched Odin that only changed 2 jump instructions.)

Unfortunately, I'm on a steep Android & Linux learning curve ... luckily I have insight into hacking Windows stuff.

Bear with me ...
[AT&T Samsung Galaxy S 5] boyhonda5:
https://dl.xda-developers.com/3/9/9....png?key=mJmrk-2q2gStVf7MToFHDA&ts=1483758088
[AT&T Samsung Galaxy S 5] wforider:
just flashed from 015 to NCE boot loader and now trying 4.4.2 crossing fingers

Recovery only no system Damm it
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Discoveries & roadblocks ...

This may all be old news to some, but ...

After finally making valid system.img files & getting through all the previous error messages, I got to a new one ... SYSTEM CHECK FAIL : (Auth)

To see what that was all about, I used a USB logger to monitor what Odin (& Loke) were talking about.

After some handshaking, Odin downloads the PIT from the phone.

Then Odin uploads 30 blocks of 1 MB to the phone, at which point Odin stops & there are error messages on both ends.

I would guess that Loke looks for something (a certificate?) in the first 30 MB

The image starts with the App folder.& looking at the first 30 MB of that, I would guess that the "magic" is in CertInstaller or possibly ConfigUpdater.

So It turns out that Odin itself is not a target for achieving root ... oh well.

It's probably worth some more effort to discover exactly what Loke is checking in case that could be a target.

Having gotten a little fluency with USB logging, another target might be KingRoot.

Looking at the Windows installed files, it's clear they are simply using ADB to push files & commands to the phone.

Much of the stuff on the windows end is encrypted (& also in Chinese), but it's possible that the ADB traffic might not be.

Has anyone had any luck getting the Windows based KingRoot application to acquire (or at least show) successful root?
[AT&T Samsung Galaxy S 5] pinheaD420:
Anyone want to buy a rooted g900a lol going back to htc ....
[AT&T Samsung Galaxy S 5] DejaVuAgain:
ext4 help needed ...

I made an error in my last post ...

When starting a flash, Odin uploads 30 MB to Loke upon which the process terminates with an authorization error.

Now I recon that the reason for this is that they didn't really want to flash the whole file to have it brick at the end with an authorization failure (having overwritten the system partition).

In looking at the first 30 MB of a stock file, I noticed that it's mostly empty with a fairly small amount of data in one area, & in looking at my structurally valid files, they are full of all kinds of stuff at the front.

Well duh ... logical & physical partitions are not the same thing!

I assumed (incorrectly) that the loop device writing was all the same, but obviously AT&T uses some kind of utility to "organize" things ... I think the "magic" is in that 30 MB block, & if that structure can be retained, it's quite likely that the rest of the file can contain anything we like, perhaps even an application with root privileges.

(I think I read somewhere that in creating an ext4 partition that it's possible to reserve space at the front ... that's possibly what we're looking for.}

The problem now is that I'm not really an Android/Linux guy ... is there anyone out there who has insight into the ext4 file system, or at least knows of utilities that could manipulate a system.img.ext4 file?

Helllllllllllp ...
[AT&T Samsung Galaxy S 5] t2vn:
Don't work on G870A
[AT&T Samsung Galaxy S 5] wforider:
perhaps experimenting with mkfs.yaffs2
[AT&T Samsung Galaxy S 5] DejaVuAgain:
No, the file system is ext4 .

I'ts supposedly sparse, but looking at the system image, it's full of zeroes, not to mention the fact that the file is 2.4GB vs 785MB when actually output as sparse.

I suspect it's a regular ext4 file ... I'm experimenting to prove that.

If that's the case, it should be relatively easy to mount it, modify it & write it out without changing the first 30MB.

At least that's the plan (if I can figure out how to mount & write the image without changing anything).

It would make things a lot easier if someone knowledgeable would chime in ...
[AT&T Samsung Galaxy S 5] AptLogic:
I'm thinking it is just a regular ext4 image. I mean if you want to "experiment" all I bet ya have to do is try modifying the image and then see if it changes the first 30MB. If you want an easy way to compare the two, copy the first 30MB of each image and put them into separate text documents, then find the MD5 hashes of both documents and run them through something like http://diffchecker.com
[AT&T Samsung Galaxy S 5] DejaVuAgain:
I use much easier ways to compare files ... for binary files I use HxD hex editor & for text I use WinMerge.

They;re both simple portable programs from http://portableapps.com

(I run everything I can "portable" to keep my system clean, using portable apps, VirtualBox & Sandboxie ... it also allows a lot of demo apps to by "renewed").

My experimenting is to get the image file mounted as a partition rather than as a mount point in an existing partition.

It needs to be the equivalent of a backup/restore operation.

I'm sure it's simple to do, but as I said before, I'm not an Android/Linux guy (although I rapidly seem to be becoming one).

Can anyone tell me how to mount/restore an image as a partition?
[AT&T Samsung Galaxy S 5] ChikhaiBardo:
Am I missing something? I have G870A with 5.0 OF3. Both versions of kingroot states device is not supported.
[AT&T Samsung Galaxy S 5] mr.oriax123:
Since using latest kingroot now disables the "try root" button I installed kingroot v4.6.2 beta 1 and let's you try to root it. Always stops at 16% though. Wonder if we could patch the button from the beta onto the latest to force it to show. Just an idea.
[AT&T Samsung Galaxy S 5] AptLogic:
mount -t ext4 -o loop system.img /mnt/android

in Linux. If you try to mount the image in Windows you will lose all of the symbolic links and metadata in the image.
[AT&T Samsung Galaxy S 5] samccfl99:
When it did work, it usually rebooted at that point and did the whole thing over and finished when it came back up...

I WISH SOMEONE REAL SMART WOULD SEND THEM A VIRUS FOR WHAT THEY ARE DOING...THEY SURE DESERVE IT!!!

I STILL GOT ROOT. I AM NO DUMMY...
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Naw, that's what I've been using & it mounts the image file in a folder "container" (/mnt/android in your case) in the system root partition.

I thought I wanted to mount it as a "native" partition to preserve all the structure, but that's not the right track.

As it turns out, I've confirmed that the system image is in fact a sparse android image file.

There's a superblock at the beginning that contains the "magic" & so far it's getting lost in all my attempts to simply read & write the stock file.

I think the answer will involve an offset past the first block ... I'm just parsing the superblock header now to try to find that number.

BTW, while 30MB are read by Odin, I'm sure much less is "looked" at.

Besides unknown code (which is probably some kind of signature or checksum), the block appears to contain a file_contexts file.

If the signature is only used for go/no go, then we're home free.

If it's in fact calculated on the embedded file_contexts file, then we probably couldn't escalate privileges to get root, but still might be able to load a reconfigured unrooted system.

That of course assumes that there isn't another check at the end.

Anyway, I'll keep banging my head against it ...

(Also, if all my tech-talk is boring or inappropriate for this thread, just let me know & I'll shut up)
[AT&T Samsung Galaxy S 5] pinheaD420:
Do NOT shut up pleassssse !!!!
[AT&T Samsung Galaxy S 5] Cruci-:
Hi guys. Just wanted to say good job and thank you for not losing hope

If only I know what I'm doing I'd be glad to help :(
[AT&T Samsung Galaxy S 5] DejaVuAgain:
progress ...

OK, but be careful what you wish for ... ;)

Just to recap, I think there's a potential Odin exploit that we may be able to use to flash custom roms (&

possibly

achieve root).

Odin decides as to whether a system image is "authorized" by reading the first 30 MB of the image & checking something.

System images are in "Android sparse image format".

For the stock OC4 image, the header information (viewable using the "file" command) is "Android sparse image, version: 1.0, Total of 656384 4096-byte output blocks in 4545 input chunks".

Using a python script (that I modified to show offsets in hex), the first portion of the sparse image format structure is:

input_bytes output_blocks
chunk offset number offset number
1 28 4096 0 1 Raw data
2 1034 4096 1 1 Raw data
3 2040 65536 2 16 Raw data
4 1204c 65536 18 16 Raw data
5 22058 2002944 34 489 Raw data
6 20b064 0 523 7335 Don't care
7 20b070 42008576 7858 10256 Raw data
8 2a1b07c 1728512 18114 422 Raw data

Given that the 7th chunk is ~42 MB, I have to believe that the "magic"is in the first 5 chunks.

Looking at chunk 5 in a hex editor shows a bunch of repeating text (ascii view) that contain

selinux.............................................u:object_r:system_file:s0...

To me that looks like an encoded version of a file_contexts file used to set selinux permissions.

(Perhaps it's an SQLite database?)

Looking at the first 4 chunks, there's a small amount of non-zero data and a large section starting at a nice neat offset (0x2000) that is filled with FF bytes & with end of 4K sector markers.

I have no idea what that structure is, but it is quite likely a marker of some sort for the authentication.

The small amount of non-zero data is quite likely the "magic" signature.

My hope is that it doesn't contain a checksum on the rest of the data in the image ... that would cause an authentication failure at the end of the flash.

So what does all this tell us?

Well, it shows that the authentication is based on the first 2MB or so of the image.

It's quite possible that once the initial authentication is done, that Odin will quite happily flash the rest of the image regardless of contents (which would give us an unrooted custom rom).

It may be possible to hack the selinux permissions to escalate privilege on an app that could provide a path to root.

My next step is to investigate what happens to the first 5 chunks when the sparse image is converted to a normal ext4 partition.

I also need to figure out how to get those first 5 chunks into a re-packed sparse image, 'cause the "normal" tool doesn't do it.

Lots more testing to do ...
[AT&T Samsung Galaxy S 5] AptLogic:
Would we be able to use some kind of hex editor or something to insert the signature manually preceding the image? That would pretty much solve the issue of losing the signature when we repack the image.
[AT&T Samsung Galaxy S 5] DejaVuAgain:
It's a little more complicated than hex editing ...

When Odin authenticates the system image file, it just blindly reads 30MB & does it's checking.

I presume that after it passes authentication, that Odin starts back at the beginning of the file & converts it from sparse to inflated, writing out chunks of an ext4 image.

(I believe all this processing happens in ramdisk ... the reason for sparse files in the first place appears to be that during flashing, data is first set up in ramdisk & then flashed to the destination partition chunk by chunk ... it's a mechanism for being able to flash large images.)

The issue (& I'm still checking this out) is that the authentication info in the first 5 chunks of the sparse image is mapped into a superblock at the beginning of the partition. When a sparse image is output from that, the leading superblock is lost (since it's probably meaningless in the context of the partition as a whole).

I'm still working my way through the structure of ext4 partitions to understand what's actually going on.

At this point my understanding is that superblocks & their associated structures are not dependent on each other ... so it may be as simple as concatenating the first superblock (containing our authentication data) with the rest of the image (although there's the image file wrapper to deal with as well).
[AT&T Samsung Galaxy S 5] DejaVuAgain:
almost ready for some more testing ...

Things are a lot clearer now ... (which is to say that I was mistaken about a few things in my last post).

It turns out that after successful authentication, Odin will in fact flash the first 30MB chunk (even though most of it is filled with "don't care" type data ... ie, not actually written).

That's because the front end of that chunk contains the superblock for the partition as well as the block bitmap, inode bitmap & the inode table.

The large area filled with FF's is in fact the completely filled block bitmap as well as a number of inode bitmap entries.

What looked like an encoded file_contexts file spans the inode table & is in the unused portion of each inode entry (bytes 156 to 255).

It think it's simply an artifact from not having zeroed out memory when the inode table was built ... ie, the partition was originally built with a "quick format".

The first 1KB of the superblock (which is reserved for a "bootloader") has what looks like artifact junk in the 2nd half.

All that leaves is one peculiar text string that has no obvious meaning ... other than perhaps being our elusive "signature".

The ASCII string is "SERPKLUA002" located at 0x7D8

That's the next target for testing ...

Update: it just got a little more interesting.

I just looked at the sparse image & the mystery string is located at a nice round number 0x800

That implies to me that the signature is simply pasted into the image after it is written out as sparse.

Let's give that a try ...
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Alpha5 ready for testing ...

I've taken the Alpha4 rom file & hex edited in what I believe is the elusive authentication signature.

Get the file here

I hope someone can test this ASAP ...

I'm really tempted to try it myself, but if it passes authentication & starts flashing, but then crashes on a check at the end, I would definitely loose my root.

(As usual, testers should be on the OC4 kernel, & be comfortable with flashing & recovery).

In recalling my "cracking" days, I always anticipated that the protections would be diabolically complex, but mostly they turned out to be pretty simple, just like what I think I've discovered in Odin.

While they may have some more tricks up their sleeve, I think we're a lot closer now ...

Also, I just noticed that the "signature" for PA2 is incremented to "SERPKLUA003" from "SERPKLUA002".

I don't have PH4 at hand, but if the same kind of signature is there, it might indicate a generic mechanism to exploit.
[AT&T Samsung Galaxy S 5] Cruci-:
Will test..

Just have to download and flash the OC4 rom in a minute

Edit: I cannot go back to OC4 :3

I'm on a marshmallow firmware. Tried going back to COI5 first then flashing OC4 and still it fails.
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Great!

I'm not really sure about the kernel compatibility, but I know that OC4 runs ok with my rom.

Looking at the "signature" more closely, I would speculate that the "SERPKLUA" part is tied to 5.x & that the "002" is tied to the bootloader/kernel version ... particularly since PA2 & PH4 have the same "003" signature.

I'm quite hopeful about this test, although there is that small mystery chunk of gibberish in the 2nd half of the bootloader reserved area preceding the superblock that could be involved in the authentication.

Standing by for your result ...

---------- Post added at 04:36 AM ---------- Previous post was at 04:33 AM ----------

Just saw your post after replying ...

Please give it a try anyway to see what happens.

I suspect it will come back complaining about the older version, but the error message would be informative in any case .

Thanks ...

---------- Post added at 04:42 AM ---------- Previous post was at 04:36 AM ----------

Hey, wait a second ...

I was on Marshmallow & was able to downgrade to PA2 before rooting (using KingRoot).

I'm on the PA2 bootloader myself running my rom with what I think is the OC4 kernel.

(It's all a little confused because I changed the build.prop & other stuff to get rid of everything AT&T.)

PA2 should work although the":002" signature suffix might be a problem ...
[AT&T Samsung Galaxy S 5] Cruci-:
Ver: COI5

<ID:0/004> Added!!

<ID:0/004> Removed!!

<OSM> Enter CS for MD5..

<OSM> Check MD5.. Do not unplug the cable..

<OSM> Please wait..

<OSM> Checking MD5 finished Sucessfully..

<OSM> Leave CS..

<ID:0/004> Added!!

<ID:0/004> Odin engine v(ID:3.1101)..

<ID:0/004> File analysis..

<ID:0/004> SetupConnection..

<ID:0/004> Initialzation..

<ID:0/004> Get PIT for mapping..

<ID:0/004> Firmware update start..

<ID:0/004> SingleDownload.

<ID:0/004> system.img.ext4

<ID:0/004> NAND Write Start!!

<ID:0/004> FAIL! (Auth)

<ID:0/004>

<ID:0/004> Complete(Write) operation failed.

<OSM> All threads completed. (succeed 0 / failed 1)

Ver: CPA2

<ID:0/004> Added!!

<OSM> Enter CS for MD5..

<OSM> Check MD5.. Do not unplug the cable..

<OSM> Please wait..

<OSM> Checking MD5 finished Sucessfully..

<OSM> Leave CS..

<ID:0/004> Odin engine v(ID:3.1101)..

<ID:0/004> File analysis..

<ID:0/004> SetupConnection..

<ID:0/004> Initialzation..

<ID:0/004> Get PIT for mapping..

<ID:0/004> Firmware update start..

<ID:0/004> SingleDownload.

<ID:0/004> system.img.ext4

<ID:0/004> NAND Write Start!!

<ID:0/004> FAIL! (Auth)

<ID:0/004>

<ID:0/004> Complete(Write) operation failed.

<OSM> All threads completed. (succeed 0 / failed 1)

I'll try finding a separate OC4 ROM because what I downloaded and flashed is a one-click ODIN and I think that's the problem, I guess.
[AT&T Samsung Galaxy S 5] DejaVuAgain:
And then what? ... after "single download"?

Did authentication fail?

As I speculated before, I think for PA2 the signature suffix needs to be "003'.

I'll make another version to test that.

(Perhaps one of the previous testers can try OC4?)

Thanks guys ...

Edit ... the posts are asynchronous ... I didn't see the tail of your last post in the quote ... so I now see that it failed.
[AT&T Samsung Galaxy S 5] Cruci-:
I copied without checking on how I highlighted it hahaha. Sorry for that

I'll be waiting for more tests cause tomorrow I'll be very busy for next week (midterms, proj etc etc).
[AT&T Samsung Galaxy S 5] DejaVuAgain:
OK, thanks ...

I'm making a version for Marshmallow that tests my "hack".

I'm taking a stock PA3 system image, removing a couple of useless APKs, patching in the signature & repackaging it.

It's a simple test to verify that the same vulnerability exists in Marshmallow.

(If it doesn't flash, I'll have to try putting in the stuff that looks like garbage at the front of the file. ... those 2 things seem to be the only things that Odin can actually look at for authentication ... all the rest is standard ext4 file system stuff.)

I'll post that separately for anyone who wants to test on Marshmallow ...
[AT&T Samsung Galaxy S 5] wforider:
testing on OC4 now

---------- Post added at 10:15 PM ---------- Previous post was at 10:10 PM ----------

<ID:0/003> Added!!

<OSM> Enter CS for MD5..

<OSM> Check MD5.. Do not unplug the cable..

<OSM> Please wait..

<OSM> Checking MD5 finished Sucessfully..

<OSM> Leave CS..

<ID:0/003> Odin engine v(ID:3.1101)..

<ID:0/003> File analysis..

<ID:0/003> SetupConnection..

<ID:0/003> Initialzation..

<ID:0/003> Get PIT for mapping..

<ID:0/003> Firmware update start..

<ID:0/003> SingleDownload.

<ID:0/003> system.img.ext4

<ID:0/003> NAND Write Start!!

<ID:0/003> FAIL! (Auth)

<ID:0/003>

<ID:0/003> Complete(Write) operation failed.

<OSM> All threads completed. (succeed 0 / failed 1)

secure check fail :system
[AT&T Samsung Galaxy S 5] Cruci-:
Glad to hear that! *Shining eyes*

I'll probably go back to MM and re-flash back if you need some tests cause lollipop drains my battery so fast and the battery approx. time left thing is not accurate and there are some features that I can't use in lollipop (S Note which I used most. Hate that basic Memo App)
[AT&T Samsung Galaxy S 5] AptLogic:
[MENTION=7958871]DejaVuAgain[/MENTION] if we can get this to work with a normal system image could we also get it to work with kernel images? Because if we can do that we've basically got most of the device at our disposal and work on a Nougat ROM could possibly start. I'm guessing the kernel image will be harder because its checked at every boot by the BL before loading it.
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Ouch! ...

"The operation was a success but the patient died".

I finally figured out the protection.

The small block of code in the reserved area is in fact the signature.

The text string is only used to enforce appropriate revision sequence.

I had mistakenly concluded that the signature area was an artifact because it was the same in OC4 & PH2, but that's not the case. When I rechecked it, they are in fact different which is of course consistent with being the signature.

I pasted the signature into a system image for upload & testing.

Unfortunately, when I was rechecking the "fail" error message on the phone, I accidentally grabbed the wrong image file & Odin flashed the image all the way to the end, whereupon it failed the signature check (exactly as I had speculated).

Of course I lost root.

What all this means is that system images are signature protected & there's no simple work-around for that.

I'll continue investigating other targets for root.

Aside from losing root, things are actually even worse for me ... somewhere along the line on one of the resets, I must have missed unchecking the re-activation lock checkbox (which defaults to checked), so I'm now locked out of my phone ...