yashsingh1/xdaforums huggingface dataset:
[Verizon Samsung Galaxy S III] xd.bx:
If Samsung did their homework, they will have an RSA blob encrypted with their private key within the emmc containing after the decryption some unique device id that cannot be changed, and the flag that says whether the phone is locked. And of course every GS3 will be doing this check, no matter the carrier. But this is just speculation, only the reverse enginnering of the SBL which Lee is working on (thanks Lee!) could prove this theory.
[Verizon Samsung Galaxy S III] mybook4:
3) extracted the stock ramdisk, modified init.rc (removed comments) to make the ramdisk smaller, cpio'ed and gzipp'ed it back up, inserted it into the stock boot.img (at 0x543000) and padded with zeros until 0x573000 (start of signature). Didn't touch the 2k header. Flashed via dd in android in terminal.

Same yellow triangle “System software not authorized by Verizon Wireless has been found on your phone...” message.

No luck, but more info.
[Verizon Samsung Galaxy S III] segv11:
So it looks like the _whole_ boot.img (not just the kernel or the first few K) are signed.
[Verizon Samsung Galaxy S III] mybook4:
Seems that way. Kind of just affirms what we thought: we need to get deeper into the bootloader itself to look for more holes.
[Verizon Samsung Galaxy S III] WildZontar:
CheatEngine in particular would probably not work, but your idea of examining the RAM to retrieve the keys is absoleutely a good shot. As you'd expect though, the operation that would yield the best results is also the hardest to do.

This is a side-channel cryptograhpic attack known as a "cold boot attack". Unfortunately, it's rather difficult. It would require something like a kernel compiled without RAM protection; this would change the default behavior in the event of an invalid pointer dereference in a program. Normally, the OS puts a stop to you trying to use RAM you don't own (dereferencing unallocated RAM leads to a segmentation fault), but without RAM protection, you can theoretically dereference whatever you want whether or not it's been allocated to you. At this point, you'd be able to dump everything in RAM and analyze it. This wouldn't be of much use because 1) the kernel is the one thing we can't change to begin with, and 2) I'm not sure if the linux kernel even has such an option.

The other option would be to look at the RAM using some sort of hardware trick, i.e. directly wiring the RAM onto another piece of hardware that could take "snapshots" of the RAM at any given point. I wouldn't count on this either as it undoubtedly requires expensive equipment, and RAM is on the same chip as the CPU making it even more challenging.

Even if you could take a complete RAM dump at any given time, you're still left with the challenge of figuring out how to get what you need out of it. In essence, you're handed a 1,073,741,824 piece puzzle with no assembly instructions.

Forensic investigators can theoretically use this form of attack, for example if there is a major fraud investigation and the suspect has a computer running at the time of evidence collection with a dismounted volume and cached key. However, to my knowledge, it's never actually been done because of the challenges it poses. For now, it remains a mere academic curiosity because of how difficult it is to do. Possible, yes. But don't count on it.
[Verizon Samsung Galaxy S III] AdamOutler:
For a "cheat engine" thing you guys want the "viewmem" binary. This will allow you to dump any memory location... Havn't tested it, but it should install the proper binaries into /system/bin. :)

Download CASUAL BHT Installer

This Cross-platform Adb Scripting Universal Android Loader package works on Windows, Linux and Mac.

I will be packing up my stuff and moving around the corner this weekend. I just want you guys to know I will be watching this thread and posting any relevant information. The best way to notify me of anything is a mention of +Adam Outler on G+ (please no questions). Obviously I will not have my computer or workbench set up this weekend and it might be a little bit until I'm able to get back into the swing.

Also, newswriters, any further articles on this topic MUST include names other than myself. I'm the recognizable face on this project and I'll take the blame if blame is needed.. But Ralekdev's post of a disassembled bootloader seriously trumps anything I've done and so far I've yet to see an article mention him and that offends me.

Samsung is running a campaign to fight rumors that they locked the bootloaders. They are telling customers that they send the devices to Verizon and Verizon locks the bootloaders. This is simply not true. That would be a redundant and inefficient step which would not make sense for business. These boards are specially made PER CARRIER. There is a different board for Sprint, Verizon and AT&T. Until one of these so-called "pre-Verizon" bootloaders shows up in Odin3 format, don't take it seriously, don't believe it, and dont repeat it. Rumors like that are designed to make people sit around and wait.

You can get your phone into Odin mode by using "adb reboot download" or "adb reboot bootloader" however there is another option. Using a 301kohm jig puts the device into Factory mode. I'm not sure on the differences.

When searching ABOOT partition for information, please inspect the difference between FACTORY MODE and ODIN MODE.
[Verizon Samsung Galaxy S III] Ralekdev:
All I can see that putting it into factory mode does is allow the odin command handler to reset the ddi info (flash counter, binary type, etc). Normally odin is still blocked from doing that.

EDIT:

More specifically, if factory mode is on it automatically clears the ddi info when the odin packet type 0x67 (kControlTypeEndSession in heimdall) is sent with the next int 0 (kRequestEndSession)
[Verizon Samsung Galaxy S III] N00BY0815:
Did anyone check, if during USB flash process, or other processes maybe a checksum like MD5 is being transfered onto the phone, which is being check right after the flash. If those two checksums are identical --> normal boot, if not --> error message... Just a thought, if this is useless, delete the post.
[Verizon Samsung Galaxy S III] stiltzkin:
If I'm not mistaken, the Linux kernel has something like this in the form of ptrace scope, which controls whether or not processes are able to examine the memory of other processes. I've encountered this recently because most Blizzard games have an active memory monitor designed to prevent the kind of side-channel cheating attacks you guys are talking about, and without first temporarily setting "sysctl kernel.yama.ptrace_scope=0" on my Linux box, those games crash WINE with a segfault. Also I believe ptrace was used to take control of the init thread to accomplish 2nd-init on phones like the Droid X as well, so I think there has been some past work on this.

If this is incorrect, trivial knowledge, or not helpful, please feel free to remove this. Thanks.
[Verizon Samsung Galaxy S III] AdamOutler:
Root owns all the memory and can access it through /dev/mem. I have never had a problem dumping memory with viewmem. The real question is where do we look for bootloaders
[Verizon Samsung Galaxy S III] Entropy512:
It's about 50/50 whether it is HMAC or whether they are using some sort of asymmetric signature algorithm.

HMAC is closely related to hashes like MD5 and SHA (MD5 is very weak though.)

If HMAC is used, the signature is something like:

sig = SHA512(message | secret);

Where | stands for "append"

Then, for distribution, the "signed image" is

message | sig

Note that you can't generate a matching sig for a given message without that secret value. The good news is that HMAC is symmetric so that secret must be stored somewhere on the destination device. The bad news is that usually this secret is burned into protected eFuse memory of the CPU and can't be retrieved without sophisticated IC reverse engineering techniques (decap the chip and probe the die).

If it's an asymmetric algorithm - then the secret used to generate a signature is not the same one that verifies it.
[Verizon Samsung Galaxy S III] mybook4:
Great work! Thanks to Lee and everyone for all the hard work!

Still looking at the code to try to get a better understanding of the algorithm but here's some food for thought:

1) The recovery partition is signed, but the signature is not enforced. Perhaps there is a link 'n' (i.e. partition) in the chain of trust whose signature is also not enforced (not very likely, or secure).

In this case, we could modify 'n' such that it does not enforce signature of latter links in the chain of trust (e.g. overwrite the signature checking function with a series of noops or trivial assembly instructions leading to a properly placed return value of 1 or "true" ).

We could then perform similar modifications to the latter links including aboot. Note: it is very likely that this isn't testable in a practical way. It was stated previously (in the 1st post) that aboot contains the daemon for odin. If we broke the boot chain earlier than aboot, we wouldn't be able to Odin over a mistake.

2) From the C, my understanding is that the contents of the signature are loaded into RAM prior to running the signature checking. Is it possible for us (with JTAG equipment to modify the contents of the memory utilized for the memcmp call (pointed to by img_ofs_0x100)? This would be more of a proof of concept as carrying around JTAG equipment to reboot the phone is a little impractical.
[Verizon Samsung Galaxy S III] enderblue:
Confirmed. I renamed the SysScope.apk file and wrote the encrypted block to signify a Samsung rom. Through multiple reboots, the pad lock icon was gone as well as the 5 second delay.

Thanks,

Enderblue
[Verizon Samsung Galaxy S III] NegativeOne:
This doesn't really get us anywhere though right? Just removing a nag screen? Good work anyway - i'm just trying to understand.
[Verizon Samsung Galaxy S III] enderblue:
You are correct. It doesn't get us much further with unlocking the bootlodaer, but it will make the standard bootup faster. I plan to work on a way to process the information and allow the user to implement this on their phone. Maybe through a standard application.

I'll go back to being quiet and learning from RalekDev.

Thanks,

Enderblue
[Verizon Samsung Galaxy S III] alquimista:
{Q} IDA Setup?

Hi Ralekdev, please post this guide. I've been manually going through and checking for commands and it is taking forever to get anywhere.

Thanks,

ALQI
[Verizon Samsung Galaxy S III] LLStarks:
Anyone know anything about this I535OYALG1 firmware?

https://glbenchmark.com/phonedetail...SCH-I535+(Verizon+Galaxy+S3)&testgroup=system

Could this be the Dev Edition firmware?
[Verizon Samsung Galaxy S III] AdamOutler:
Alright guys. I have been moving and I've been busy. Just got internet hooked up today and it will probly be next week before I'm back up and running. I'm on my phone now.

Had a great idea for a recovery/kernel wrapper and just wanted to post about it.

We can flash a custom recovery but not a kernel. We can flash a custom kernel but not a recovery. What we need is a wrapper for the kernel. Something which will deploy into memory, then give us the option to boot normally into kernel or recovery. Here's a base to start with: http://www.xda-developers.com/android/cyanoboot-for-nook-tablet-released/

1. It will take some coding, but if we can load a custom cyanoboot+recovery+kernel, we have our custom recovery and a custom kernel.

2. Another option would be to build a new CWM recovery with a startup delay to allow you to press a certain key to enter recovery or press another to simply boot. The boot.IMG format supports multiple kernels in a single wrapper if I remember correctly.

Option 2 would probly be the easiest.

However the problem still remains that the user must download a 600 meg system partition and flash it in order to root the device. This leaves a lot of room for user error and it takes a lot of bandwidth.

So basically we can have a simulated unlock by flashing a custom SYSTEM through Odin and then a custom RECOVERY through CASUAL. Anyone have time to code it?
[Verizon Samsung Galaxy S III] Cvballa3g0:
For option 2, a developer named Hashcode actually had this method with most of the Moto Devices on Verizon. The phone would boot and ask if you wanted to go into the recovery, or skip to boot. Within "Safestrap" (the recovery name) you could do all sort of things that CWM could do, but you also had the ability to go into a "Safe" mode where you could install a second ROM to your phone with the "Un-Safe" uneffected. It worked flawlessly and maybe you could send him a PM about developing on the S3.
[Verizon Samsung Galaxy S III] invisiblek:
I have a way around this...join me in IRC sometime...
[Verizon Samsung Galaxy S III] AdamOutler:
I don't think that would work because we cannot change the size of the partitions or we get problems. We basically need a Recovery/Kernel partition with a selection menu.
[Verizon Samsung Galaxy S III] x86cowboy:
Yes, please post a guide on loading it into IDA... I'd be interested in taking a look at this too.
[Verizon Samsung Galaxy S III] M4gicM@:
Hey Adam just a quick FYI another root method is being toyed around with over here http://xdaforums.com/showthread.php?t=1792342. It is basically the same thing that was done with the Transformer Prime. This would eliminate the need for a 600mb image just to root.
[Verizon Samsung Galaxy S III] Rob_Storm:
I can verify it works perfectly.
[Verizon Samsung Galaxy S III] cdesai:
@AdamOutler your second idea can be easily achieved.

1. Rename the init binary to something else, and make it a script instead

Make it grep dmesg for a key press, and if a key is pressed, copy the normal init.rc and other files and then exec /realinit.

^Quick and easy to do :)

2. Move the recovery one step down, and present a boot menu instead of recovery, with options to boot into android, boot to recovery, reboot and power off - and p do accordingly.

^Complicated but better :)

Sent from my GT-P1000
[Verizon Samsung Galaxy S III] appye:
With a default timeout to Android! Say five seconds? This is how i set things up on the Windows PC 's in our network.

If my post here is inappropriate, i understand if a mod deletes it...
[Verizon Samsung Galaxy S III] MichaelVash7886:
That would be a good idea.

Only thing is the current root method to get to this could be easily patched via an OTA right? I mean it's still building off the inital root method found by inviblek right? I heard that would be easy to fix and Verizon was already planning an OTA to address just that. Unless this newer root method is more difficult to block.
[Verizon Samsung Galaxy S III] NegativeOne:
Moot point. We block OTAs
[Verizon Samsung Galaxy S III] Desterly:
I've started to modify the boot menu we used on the X to accomplish this.. although I'm not that far and I'm sure someone could do it far better than I.

The idea being boot from recovery partition -> custom kernel -> led flashes blue

-> User hits the volume down key -> custom menu shows w/ option to reboot or recovery

-> User hits nothing, rom boots as normal.

The only problem that I would see (and this might already be solved) is that the users will have to choose to boot from recovery from cold boot
[Verizon Samsung Galaxy S III] con247:
Alot of people, including me, will probably buy the phone after an OTA.
[Verizon Samsung Galaxy S III] tonu42:
Just saying what all of you are suggesting we do with this whole boot process thing has been done already if I am not mistaken. The KEXEC boot-hijack does what all of you are saying. And its automated too instead of selecting.

my 2 cents, delete if what I said isnt related.
[Verizon Samsung Galaxy S III] AdamOutler:
Kexec boots the device then reboots into another kernel. We are talking about a single kernel with a recovery built in, just like the Galaxy S series has had in the past. No kexec hacks. We aren't extending boot times. This method will work better than kexec.
[Verizon Samsung Galaxy S III] flamus:
Won't this require a full reflash for a new (or different from rom) kernel?

Maybe I have been spoiled with my DINC1 and on the fly flashing / unbricking my phone. :-\
[Verizon Samsung Galaxy S III] Desterly:
Yes/No

you have to flash the new rom as is however rom's are installed via an installer script (in CWM). there's no reason the zip couldn't contain both images w/ instructions to flash them to the recovery partition.

and updating the kernel would be as easy as a dd into the recovery partition.

If the initrd was configured to point to the system drive or sdcard or another location as well there is no reason you couldn't just update the kernel w/out having to update the recovery/boot

The only downside I see is getting the device to always boot into recovery w/out having to hold down keys to do so... but that might just be the trade off for custom roms of this sort
[Verizon Samsung Galaxy S III] flamus:
Yeah. Friend has SGS2 Epic 4G Touch and has to do this. Just have to test roms before heading from the computer, since not as easy to flash on the go.

No opposed to this method. Just setup Arch Linux (XFCE4+SLiM) and Win7 dual boot; so not afraid of doing this.

Thanks 4 information.
[Verizon Samsung Galaxy S III] ericerk:
So basically since a proper unlock solution can't be found kexec is here to stay?
[Verizon Samsung Galaxy S III] irtehun:
Kinda sounds that way
[Verizon Samsung Galaxy S III] TechSavvy2:
Read OP.
[Verizon Samsung Galaxy S III] alquimista:
{q} samsung_mdm

I've been fiddling with my SGS3 and a Mac, as I've run into a complete block on trying to dissasemble the bootloader (plus ralekdev seems to have that covered).

The only interesting thing that I have found so far is that I can connect via USB while the device is in ODIN Mode, and it shows up as SAMSUNG_MDM in sysinfo. I can then actually connect to that device via serial terminal. Problem is, I don't know any commands to send. Usually when I talk to a device over serial there's a menu, but there's no menu that I can find.

Here are the settings that I used to actually connect to the device (using GoSerial):

Serial Port: SAMSUNG_MDM

Speed: 115200bps

Data Bits: 8

Parity: None

Stop Bits: 1

Hardware Flow Control

Input: RTS

Output: CTS​

MDM usually stands for Mobile Device Management, as in being able to lock or wipe the device remotely. I'm not sure why this would be available while in ODIN mode, since that kind of mobile management is done via a server and not a direct serial conection. Point is, since the device is in Odin mode, maybe we can poke at it and see what comes out.

Does anyone know anything about this? Any settings or commands?

I'm going to post a list of all the strings I could find while trying to disassemble the bootloader in a separate post.

Thanks,

ALQI

---------- Post added at 05:14 PM ---------- Previous post was at 04:16 PM ----------

I posted an edited version of all the important strings I could find in aboot. I deleted anything that I thought was not relevant to trying to research the bootloader (images, nonsensical data, etc).

Here's the link to pastebin for what I put together:

SGS3_aboot_Strings

The bootloader pretty much looks like the (L)ittle (K)ernel bootloader mentioned here:

CodeAurora - LK Base Android Bootloader

The source for the LK bootloader can be found here:

CodeAurora lk Git Repo

There's one string in particular that I am interested in:

ERROR: Could not do normal boot. Reverting to fastboot mode.

This is from the aboot dump, not the source code. Would it be possible force this error to happen and thus get into fastboot mode?

Ta Very Much,

ALQI
[Verizon Samsung Galaxy S III] Ralekdev:
That's from aboot_init, decompiled version available http://pastie.org/4339731
[Verizon Samsung Galaxy S III] mastamoon:
This boot menu thing sounds like moboot for the hp touchpads running cyanogenmod.
[Verizon Samsung Galaxy S III] ScottIsMyName:
Where is the try_get_boot_type procedure? It seems like that might enable us to get to fastboot if we could find out what that procedure is doing to return true/false. If we can get it to return false, it seems like it might possibly reboot to fastboot?
[Verizon Samsung Galaxy S III] Jiggity Janx:
Safestrap and its predecessor "Bootstrap" do what you are looking for. And they are done on a bootloader locked device on the same network with the same Verizon warning messages. I wont mess up the explanation again but I do recommend talking with hash0fcodes. He may already be working on something for it as he collabs with dhacker29.
[Verizon Samsung Galaxy S III] jbzcar:
That's exactly what I was thinking, couldn't place it, though. :)
[Verizon Samsung Galaxy S III] alquimista:
{Q} aboot.c

That looks like it comes from the aboot.c source here http://pastie.org/4340093

Note: CodeAurora does not endorse anything I am doing. However, I am following the copyright instructions to the letter.​

However, I don't see any of the strings from the target_fastboot_init section. ie:

fastboot_register("continue", cmd_continue);
fastboot_register("reboot", cmd_reboot);
fastboot_register("reboot-bootloader", cmd_reboot_bootloader);
fastboot_register("oem unlock", cmd_oem_unlock);
fastboot_register("oem device-info", cmd_oem_devinfo);
fastboot_publish("product", TARGET(BOARD));
fastboot_publish("kernel", "lk");
fastboot_publish("serialno", sn_buf);

Wouldn't "oem unlock" show up as a string if it were accessible?

Ta,

ALQI

EDIT: Also, what does this mean?

#define FASTBOOT_MODE 0x77665500
[Verizon Samsung Galaxy S III] Ralekdev:
The aboot in the SGS3 is heavily based on lk, but also modified in certain areas. One of the places they changed was fastboot, where they replaced it with 2 other boot modes instead (odin and rdx). The normal fastboot stuff is mostly gone.

Setting the restart reason (at 0x2A03F65C) to FASTBOOT_MODE will make the phone boot into fastboot upon reboot even if the key combo isn't pressed. There are a few more possible values in the post from Adam earlier in the thread where he pasted the email I sent him.
[Verizon Samsung Galaxy S III] LLStarks:
Here's the older I535VRALEC bootchain that's been whispered about:

http://goo.im/devs/invisiblek/i535/VRALEC.bootchain.tar.md5

This bootchain permits flashing a recovery from Odin for easier rooting. Rest of the bootloader is still locked.
[Verizon Samsung Galaxy S III] open1your1eyes0:
How on earth did you get this? Is this the infamous engineering bootloader that everyone rumored about? Safe to flash and if anything be able to flash back the original?
[Verizon Samsung Galaxy S III] LLStarks:
This is the pre-release bootloader.

[ROOT] VRALEC Bootloader - Allows us to Odin a custom recovery
[Verizon Samsung Galaxy S III] alquimista:
How would I write that restart reason into the params?

ta,

alqi
[Verizon Samsung Galaxy S III] enderblue:
The Params block (mmcblk0p10) doesn't address that high. I pulled that address from the mmcblk0 block and the existing data doesn't seem to suggest a current reboot reason.

What part of the memory is that address referencing?

Thanks,

EnderBlue
[Verizon Samsung Galaxy S III] Ralekdev:
That's not an offset into the mmc, but rather part of the MSM_SHARED_IMEM_BASE region of memory. To write to it aboot does *(int*)0x2A03F65C = restart_reason, but depending on the current environment you may need to do more work to write there. Check arch_reset() in arch/arm/mach-msm/restart.c in the kernel Samsung released for how they do it.