yashsingh1/xdaforums huggingface dataset:
[AT&T Samsung Galaxy S 5] AptLogic:
Damn... I was getting so hyped up! lol.

As for the FRP, here's your way out: http://www.androidauthority.com/samsung-factory-reset-protection-bypass-in-minutes-653308/

Maybe we could revisit the Dirtycow concept...
[AT&T Samsung Galaxy S 5] samccfl99:
:rolleyes:

Please wake me up when you find a permenant root solution so I can breathe a bit better hoping my phone does not crash, turning it into a paperweight. OH, I guess I could put MM on it and sell it then, because it would be perfectly useless to me.

STILL ROOTED...:laugh::laugh::D
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Next gambit ...

As I said way back, all this ground has probably been covered before, but I now have a definitive answer as to why there isn't a "simple" Odin vulnerability as far as .tar.md5 packages go.

Next, I'm going to do the same with zip update packages.

I need to watch the USB traffic to see what work Odin is doing as apposed to Loke.

It's hard to imagine that the bootloader/kernel is authenticating all the writing of all the little bits so there may be an opening to patch Odin (which is relatively very easy).

And if that isn't fruitful, I'll have a look at why no-one has attacked the bootloader to neuter it ...& after that who knows?

There are certainly opportunities beyond where most people are looking, which seems to be vulnerabilities in Android itself.

On the other hand, KingRoot has had success there ...
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Something else to try ...

There may be another "generic" way to use Odin to flash a modified system image ...

Odin pushes the system image up to Loke in 30MB chunks that are cached before being "un-sparsed" & written to the system partition.

Given the sparse nature of the input file, Odin must at some point tell Loke that EOF (end of file) has been reached, at which point Loke completes the authentication check.

The question is "how is the system disabled?".I

The error message in the phone's system log indicates that the system image fails to mount if unauthenticated.

It's unlikely that the partition table entry is "damaged", but it's quite likely that the system partition itself gets trashed, easily done by overwriting the superblock at the front, or whatever.

If the Odin programmers were really rigorous, the superblock would be cached & not written until after authentication, but perhaps they left a hole there, ie. they do something to disable the otherwise ok partition.

We know from flashing the pre-rooted OF3 that once a system image is resident, it can be brought to life after the system recognizes that it is foreign software, by simply reflashing the Kernel.

What we need to do is to get a complete system partition flashed without incurring the authentication check at EOF.

To do that, I'm going to try to patch Odin to simply exit (or pause) at EOF at which point we reboot the phone & with any luck get the system image to mount & come back with the non-AT&T software error.

The other thing that needs to be done is to pad out the last chunk to 30MB & to add another dummy chunk so that Loke writes out the files in the last chunk.

There are a few "ifs" in there, but it sounds plausible.

If it works, it would be applicable to all Odin flashable systems ...
[AT&T Samsung Galaxy S 5] NavSad:
Do you think we could try modifying the init script the way Root de la Vega did?
[AT&T Samsung Galaxy S 5] wforider:
That's where it all starts
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Actually, the first step is to be able to flash a non-stock system image successfully.

If we can do that, then we will be able to modify pretty well anything & everything.

There may or may not be a hole in Odin between the end of the upload & the authentication by Loke.

I'm hoping that Loke doesn't invalidate the system partition by default (before authentication).

I know that I can construct a system image that will flash to the end.

I'm going to insert a dummy 35MB file at the end of the image to force the last valid file to be flashed & then I hope to be able to halt Odin without signalling Loke.

If my understanding of the ext4 partition structure is correct, I think there's a chance that the system partition will mount.

I'm going to check that out ...

Update:

In looking at the sparse image format, rather than inserting a dummy file, I think all I need to do is to insert a 12 byte chunk header of "don't care" data type specifying the data length.

I'm going to start off specifying a size that will overflow the system partition (just to see what happens).

Who knows? We might get lucky & crash Loke without invalidating the system partition ...
[AT&T Samsung Galaxy S 5] NavSad:
Do you mind telling me what this Loke is you are talking about?
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Loke is the name of the bootloader/recovery software that Odin talks to on your phone.

(There's a text string in Odin identifying it as such ... it makes for a nice easy reference).
[AT&T Samsung Galaxy S 5] PopTartKing:
If you do manage to find an exploit in Odin, would it become compatible with many other Samsung phones?
[AT&T Samsung Galaxy S 5] DejaVuAgain:
The hack would be in Odin, but the potential for an exploit is in how Loke is coded.

It all revolves around whether the system partition is marked as invalid prior to authentication.

(The rest of the system is quite tight, so it's quite likely that there's no hole.)

If there is a hole, then it's very likely that it would apply to any phone that is Odin flashable ...
[AT&T Samsung Galaxy S 5] wforider:
Well, in Norse mythology, just as Odin is the ruler of the gods, Loke (or Loki) is generally accepted to be some sort of god-like figure.

Loke is the software component that runs on the Galaxy S and is responsible for communicating with Odin during the flashing process. It is initialised in the second stage boot loader (when Volume Down + Home are held). Odin is then able to issue a series of commands to Loke to instigate the flashing process.:cyclops:
[AT&T Samsung Galaxy S 5] NavSad:
That's not the right Loki.
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Partition overflow test ...

I'm investigating a potential exploit (much farther along in the boot process than that described above).

I've made a slightly modified stock PA2 system image (to invalidate the signature) that will attempt to fill & overflow the system partition on the phone.

This will definitely crash, but I need to know where & when.

Since Odin starts a connection by downloading the PIT (partition information table), it may do the math & figure out the sparse image will be too big after inflation.

If that's the case, it will be the first thing that needs to be patched in Odin.

If it hangs in Odin when it attempts to upload past the end of the PIT info, then that will be the next patch target.

If the crash comes in Loke, then the patch will be different.

Of course there may be no hole at all.

I need someone to test this & report on exactly what happens in Odin & on the phone.

The file is here.

If by some fluke, the image loads all the way to the end, it may be possible to pull the cable just before the end & have a valid system partition on the phone (unlikely, but possible).

By timing how long it takes to crash, it may be possible to catch it a second or two before then (although that may not work in this test because I'm not actually writing data, but rather just inflating "don't care" type chunck headers).

Depending on the results, actually writing overflow data may be the next test.

This is of course the ultimate aim ... to halt the flash with an intact system partition.

Given the apparent vulnerability as described above (ie, writing non-validated data before signature checking), there is a possibility that a hole exists.

I would test this myself since I've lost my root anyway, but I haven't fully cleared the reactivation lock on my phone yet, & I need it for the next few days (since I'm travelling out of town).

Big thanks to the testers ...

Edit: Just another thought ... if you're going to test this, you should post your intent here so that others don't bother to download the fairly large file.
[AT&T Samsung Galaxy S 5] AptLogic:
SamDunk will not work on our devices because:

We have Toshiba eMMC chips, not Samsung chips

We don't have an engineering kernel to flash even if we DID have Samsung chips
[AT&T Samsung Galaxy S 5] wforider:
Which chip?
[AT&T Samsung Galaxy S 5] AptLogic:
If you read the full SamDunk thread you would see that it is only for Samsung eMMC chips. The UID (the big long number thing in your screenshot) for Samsung chips begins with 12 (or 13 I forget). The UID for Toshiba chips, which are not affected by this vulnerability, begins with 11, as seen in your screenshot. Therefore, our G900A is NOT compatible with SamDunk, which made use of VENDOR-SPECIFIC commands to do its job, commands we don't have for Toshiba chips.
[AT&T Samsung Galaxy S 5] wforider:
Going back to sleep
[AT&T Samsung Galaxy S 5] PopTartKing:
If you do manage to have the image load all the way, would you need to have Odin give out some sort of signal so that you'd know when to pull the cable? Won't you have a corrupted system partition if you pull halfway through loading? Sorry for the dumb questions, I'm still a noob at this.
[AT&T Samsung Galaxy S 5] DejaVuAgain:
This is just a preliminary test to determine where to attack Odin.

If it works, I'll patch Odin to stall Loke without disconnecting ... ie prevent Loke from timing out & trashing what I hope will be a valid system partition.

I'm trying to get a handle on what happens at EOF.

While based on reasoned inference, it's all very speculative at this point ...
[AT&T Samsung Galaxy S 5] PopTartKing:
I hope everything works out for you man. I'm rocking a Galaxy Alpha and I'm hoping that this potential exploit can cause for some developers to take action. BTW, is the system partition tied in with the kernel or is it something else entirely?
[AT&T Samsung Galaxy S 5] ryanbg:
Correct. Even if you had Samsung eMMC, you are still missing a developer signature blob. Verizon and ATT use different keys for that. I've never seen an ATT sig or heard of anyone having them.
[AT&T Samsung Galaxy S 5] Vesnyx:
Quick question regarding this. Wasn't the exploit changing the CID to a developer edition CID, thereby giving the user dev device standing? If this is the way the exploit worked, is there a way to reverse engineer the method used to decrypt the CID and generate a working dev CID for our device?
[AT&T Samsung Galaxy S 5] AptLogic:
The CID isn't the main problem. Even if by some miracle we get a dev edition Cid and Aboot, you still have the problem of CHANGING the Cid, which you can't do without vendor specific commands and dumping the EMMC firmware. The only way we were able. To modify the Samsung chip was they released their vendor commands due to a bug in their chips. This will likely never happen for Toshiba chips so this exploit is a dead lead.

Edit: what if we were to dirtycow a modified init.boot.sh in the /etc directory that passes the command "setenforce 0" when run. Wouldn't that script run at boot as a system process and disable SeLinux? It would be a small step, but it would probably help.
[AT&T Samsung Galaxy S 5] Vesnyx:
Reason I asked was because my CID begins with 15, and as far as I know, this chip is exploitable through beaups's SamDunk method. Therefore, I can change the CID, which is why I'm asking if there's a way to reverse engineer the signature verification method used to verify that the device is a developer edition, or in this case an unreleased AT&T engineer device.
[AT&T Samsung Galaxy S 5] AptLogic:
Interesting.... well even if we were to change the CID you would have to have an engboot for this specific device, which we don't have.
[AT&T Samsung Galaxy S 5] wforider:
What if you could buy one?
[AT&T Samsung Galaxy S 5] AptLogic:
That doesn't sound very possible.. the only way you could get something of this nature is if either Samsung releases it or someone leaks it.
[AT&T Samsung Galaxy S 5] Vesnyx:
And this goes back to my original question. Isn't the only purpose of the eng boot to get the new CID? The process used for the G900V simply changes the CID, I don't recall them having to flash a different boot. If I recall correctly the boot was the same between the two and the CID being verified was what made it considered a dev device.
[AT&T Samsung Galaxy S 5] AptLogic:
​

Well I guess we can try just changing the CID and then attempt to flash a custom recovery for the t mobile variant.
[AT&T Samsung Galaxy S 5] Vesnyx:
Change it to what CID though? Brute forcing isn't exactly a fast way to gain dev access. I feel like there's a certain algorithm used to verify developer status. Flashing it otherwise won't do anything.
[AT&T Samsung Galaxy S 5] AptLogic:
I think this is why we need the Aboot image... I'll look into it tomorrow.
[AT&T Samsung Galaxy S 5] Vesnyx:
Again I believe that the only difference is the CID that's located in the dev aboot image. We know that there is a function that verifies that the device is a dev edition, but where this function is located what I'm trying to figure out. We might be able to exploit that function to generate a working CID and gain dev access.
[AT&T Samsung Galaxy S 5] TheMadScientist:
so i got ones of these i can throw out for testing purposes

its on of3 never been upgraded past it.

so what im looking at is of3 is older the oi5 so technicly i cant downgrade but upgrade to oi5 kingoot and sume. all that good stuff and ill have sticking root through reboot?

can i just root of3 or do i have to to upgrade?
[AT&T Samsung Galaxy S 5] invert_nexus:
Kingroot stopped working. But, by all means, try. It won't break anything and maybe it'll work again.
[AT&T Samsung Galaxy S 5] AptLogic:
Well due to Kingroot not working I think you should just stick to OF3 for now. We've got a couple things that we're working on and we should be able to root again at some point.
[AT&T Samsung Galaxy S 5] TheMadScientist:
thank you for your response so what ive tried so far in odin getting fails andi think qfuse 4 is the antirollback kicking in too????
[AT&T Samsung Galaxy S 5] AptLogic:
If you're getting a "fused 4 > binary [X]" error then that is indeed the antirollback kicking in.
[AT&T Samsung Galaxy S 5] TheMadScientist:
yup i figured

well i got plenty of devices layin around so mines up for testin purposes if its needed out there
[AT&T Samsung Galaxy S 5] AptLogic:
Alrighty thanks for your help. I'll let ya know if there's anything that needs some testing done :)
[AT&T Samsung Galaxy S 5] AptLogic:
link is broken :/
[AT&T Samsung Galaxy S 5] Goron_Elder_Chris:
Is there anyway to root?

I read header and I tried towelroot, is there any form of bypass just to get root on lolipop?
[AT&T Samsung Galaxy S 5] PopTartKing:
I know I'm not one to talk, but can't someone with root just make an Odin backup, or is it impossible with the locked bootloader?
[AT&T Samsung Galaxy S 5] pinheaD420:
This has been answered many times .... We have no root method currently .... Please learn to read past the header ....
[AT&T Samsung Galaxy S 5] TheMadScientist:
ive always wondered this myself

only issue i forsee is device specific info such as iemi and such also being backed up
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Not broken per se ... I removed the file since I ended up doing the test myself.

I've confirmed that there are no "holes" at the end of a flash,

I'm setting up another test to determine at what point the system partition is invalidated.

I suspect that it happens before anything new is flashed after the initial header verification ... that would mean no direct flashing exploit.

Since I can flash a whole image (that's rejected at the end), depending on how the system partition is flagged as invalid, there may be a possibility that flashing a PIT over top of it may reset it.

I'll try that as well.

After these tests, I'm going to look at older versions of Odin to look for opportunities from when times were simpler ...

---------- Post added at 05:51 PM ---------- Previous post was at 05:44 PM ----------

There's no problem making a backup of a rooted system & restoring it ... if you're rooted.

The issue is getting a non-stock system image flashed on an unrooted system.

I am exploring that (unsuccessfully so far) ...
[AT&T Samsung Galaxy S 5] AptLogic:
Stock OF3 zip has been posted in POST #2

IDEA: What if we were to dirtycow wpa_supplicant? Its one of the biggest files in the system directory and seems to be owned by root, so wouldn't we be able to root our device by overwriting the file with a su installer, and then turning wifi off and back on?
[AT&T Samsung Galaxy S 5] Helgen:
Why exactly did kingroot remove the root anyway? Mine is still rooted from it but I actually wanted to go to official stock firmware, now I'm worried I will lose my root... Could I move on to a rooted firmware or something?
[AT&T Samsung Galaxy S 5] AptLogic:
There's a prerooted stock OF3 you can use in Post #3

Also, can someone that knows more C than I do walk me through coding something that disables SELinux and installs root? I got the root installation down, now I just need to disable SELinux
[AT&T Samsung Galaxy S 5] wforider:
Android?
[AT&T Samsung Galaxy S 5] AptLogic:
Yep. I'm trying to overwrite the fsck_msdos utility using dirtycow so that I can disable SELinux and install the SU binaries, which should be enough for root. I've figured all I've gotta do is overwrite the fsck utility to run a shell script (located in /data/local/tmp) as root that will do all the disabling and installing. If that doesn't work then I'll try porting the shell script to C and then dirtycowing the wpa_supplicant and then try that.
[AT&T Samsung Galaxy S 5] DejaVuAgain:
rooted PIT required ...

Could someone please dump a PIT file for me from their rooted phone?

After much investigation I've found the code in Odin that invalidates the system partition on the phone.

I haven't analysed the data sent yet, but I suspect that Loke itself does the invalidation as a predetermined step in the flashing process ... that means no exploit here.

What I have found though is that after flashing a non-stock rom successfully, I get the usual authentication error & subsequent inability to boot past the bootloader screen.

If I then flash the stock PIT, I get a boot loop which tells me that booting has made it past the bootloader screen & now gets hung up at trying to mount the system partition ... haven't checked the logs yet, but I've seen that before).

I think the bootloop (inability to mount the system partition) is a result of the partition table entry for the system partition is not set as "primary".

While the PIT file doesn't map directly to the partition table in the system partition, I think there's a (small) chance that the active partition info might be written out in the PIT.

Let's give it a try, OK? ...

Does anyone else have any ideas as to how to break out of the bootloop (without reflashing a stock image)?

After breaking my system, I've restored by flashing only the system image (that I pulled out of the stock AP file).

That has prevented me loosing my setup & data.

Perhaps flashing everything else (besides the system image) & clearing the cache, etc might get it to reboot?

Any thoughts? ...
[AT&T Samsung Galaxy S 5] AptLogic:
Have you tried just reflashing the kernel to see what happens? Might be a long shot but I've seen it work in one or two cases.
[AT&T Samsung Galaxy S 5] DejaVuAgain:
Ya, I've tried that ...

It works when the error is "non-AT&T software detected".

The "error" here is that the system partition is not mountable (which I suspect is a result of Loke flagging it as not being a primary partition, or hidden or whatever.)

I'm hoping that one of the undocumented fields in the PIT records is in fact the required flag.

Flashing a rooted PIT over my rom will settle it ...
[AT&T Samsung Galaxy S 5] AptLogic:
​

In that case I think [MENTION=5042884]samccfl99[/MENTION] can help you out with the PIT because he's still rooted.
[AT&T Samsung Galaxy S 5] TheMadScientist:
i see everyone talking about loke is that the same as on lg loki ?

the one that found the workaround in the g2 bootloader

---------- Post added at 05:46 PM ---------- Previous post was at 05:42 PM ----------

So are the samsungs about the same as the lg g4 the bootloader is encrypted with a 256 bit key and the bootloader checks for signed images be it updates or .tar ?

if thats the case u guys oughta read up on 256 bit encryption at this point in history and time not brute forceable so the only way around is to make the bl think im flashing a signed image?

im trying to jump on ure guys train here and do my own testing with various images and such.

im trying to find a workaround for the missing oem unlock switch in dev options

if im not mistaken that has some to do with kingroot not working. not all but a shot in the dark
[AT&T Samsung Galaxy S 5] TheMadScientist:
so im also wondering if u guys want chen out the lgg4 ls991 sprint thread rooted system zv6

lg uses .tots instead od .tars for restored basicly we iject super su into system and use the dd comands from download mode to push the new system in place of the old leaving with a locked bootloader and root

no twrp

of coarse the dd commands for the system blocks and such would be differ on a att samsung than a sprint lg but once i get the location ima give it a shot

you put the rooted system image on intern sd and

for example ls991 type dd if=/data/media/0/system.rooted.LS991ZV5.img bs=8192 seek=65536 count=557312 of=/dev/block/mmcblk0

that pushes the rooted system and bam its rooted this only works on zv6 which is 5.1 i think and again oem unlock has to be clicked

---------- Post added at 05:32 PM ---------- Previous post was at 05:17 PM ----------

this is sort of a good sign so far

my pc reconizes it

so i need a diag port open any one know how to on the s5?????

D:\LG_Root>ports.bat

D:\LG_Root>reg query HKLM\hardware\devicemap\SERIALCOMM

HKEY_LOCAL_MACHINE\hardware\devicemap\SERIALCOMM

\Device\ssudmdm0000 REG_SZ COM6
[AT&T Samsung Galaxy S 5] AptLogic:
I would try just going into Download mode or recovery. And we don't have an OEM unlock switch.
[AT&T Samsung Galaxy S 5] TheMadScientist:
no crap i didnt think of that

onlytime my lg picks up the diag port is in download moe and i had the system booted.

thank you good sir

---------- Post added at 05:54 PM ---------- Previous post was at 05:45 PM ----------

sorry off topic

see u got some beefed up pcs compared to mine

you know anything about uefi

while back i was updating my bios had to switch to legacy compatible mode after all said and done ive lost my drivers for hdmi

video still goes through hdmi but tv switches it to dvi input even thought its still hdmi and i have no sound unless i plug into the heaphone jack now

ive updated and reinstalled my drivers but no go

i dont wanna tell u my pc cause im so ashamed of it piece of junk walmart special acer aspire

runnin 4 gb ram 1 tb and 2 500gb seagates. 4core 20 ghrt
[AT&T Samsung Galaxy S 5] AptLogic:
That sounds more like a driver problem than a BIOS problem. You should check Acer's website for drivers and make sure they're all installed and up to date. If that doesn't work out then the most you can do is try reinstalling the BIOS. I had a non-UEFI system with an HDMI input with specs similar to yours (running as my internal server now) and never had a problem like that after a BIOS update.

Any other questions just ask.