yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] ndowens:
Does anybody know if mobile tech video would do this to my phone and guarantee its safety lol

Well after this post I noticed they do offer this service,I may order it sometime so I won't be afraid of installing roms
[Captivate Android Development] AdamOutler:
Well, since youre advertising in my thread... Maybe you should consider donating to the team.
[Captivate Android Development] tokafondo:
Hello.

I'm following all this stuff about UART - USB - JTAG.

I have a GT-i9000.

I think instead of soldering, maybe this adapter could be used.

But that's what I believe... could it be true?

In all, what I want to know if is there a way to access de OneNAND and try to achieve what seems to be impossible: fix a read only internal sd.

Maybe in some of the IPL, PBL or SBL there are commands that allows what flashing, wiping, or adb'ing cannot do.

Thanks.
[Captivate Android Development] laughingT:
I assume you are talking about overcoming the EU bug from ics, yes?

I'm curious, if that's what you are thinking about. If so, what leads to the idea that a read only state of the nand is the problem? can one read the contents, but not write to it? Adam O may know with all of his UART/JTAG experience.

sent via carrier pigeon via cm10.1 Knightly, Keira.
[Captivate Android Development] tokafondo:
Well, I've made my research on the matter.

There are several reports that the internal sd memory of a phone gets unavailabe or at least 'read only'.

http://xdaforums.com/showthread.php?t=941139

http://xdaforums.com/showthread.php?t=1530034

http://androidforums.com/samsung-galaxy-s/245701-internal-sd-card-read-only.html

...and some others, including me.

I think the EXT_CSD register of the emmc card gets some kind of 'protected' or 'read only' status because of some kind of bug or trigger when flashing.

And I think that maybe by using a JTAG cable or by issuing IBL, PBL or SBL commands, some thing can be done.
[Captivate Android Development] laughingT:
hmmm. maybe a hardware problem as alternative. is it possible that some bad bits, e.g., unwritable, could lead to read only state?

did you look at this?

http://xdaforums.com/showthread.php?t=1823918

sent via carrier pigeon, jungle drums and smoke signals.
[Captivate Android Development] mrnapolean1:
Some of your images are broken. :(
[Captivate Android Development] :
So does this mean I could install different linux distros onto this device and the will boot, like how you can do with the raspberry pi?
[Captivate Android Development] shinji257:
I have a Captivate still (it is my retired phone) and as far as I know it works still. Would someone be willing to do the unbrickable mod for me at all? I don't trust my own soldering skills.. XD

PM me if you are willing to do so. I'm located in the US.
[Captivate Android Development] AdamOutler:
I ask for $35+shipping cost, which is usually $7.
[Captivate Android Development] G-Man.:
[MENTION=3682533]AdamOutler[/MENTION] - I have a Captivate that isn't exactly bricked, in the sense that it will go into download mode, successfully flash with odin, but wont boot past AT&T boot animation or samsung S logo... screen just goes black after... would this mod allow me to fix this somehow? if so, Id have no qualms about paying you to do this. Just P.M. me with info/instructions
[Captivate Android Development] AdamOutler:
If you can get in download mode, you don't need this.
[Captivate Android Development] G-Man.:
Says it can't mount /data after Odin flash... then does what I described in my previous post. Any suggestions?

Swyped on my awesome 64Gb 1+1
[Captivate Android Development] G-Man.:
[MENTION=3682533]AdamOutler[/MENTION] - Now says that there was a firmware upgrade problem, try recovery - but cant get to recovery, or download mode... this is the ONLY screen that comes up now.... Should I assume that this device is simply dead?
[Captivate Android Development] AdamOutler:
sounds like it, sorry.
[Captivate Android Development] whyareyou:
I guess this would work if you are on a Samsung sourced ROM. Will it work on Cyanogen based roms as it uses mtd?

I noticed there is bml12 on my device, will that help?
[Captivate Android Development] TheEscapist:
Just requires reading from a different device. The overall idea still works.
[Captivate Android Development] Rebellos:
woops, forgot to attach file

hello world v0.2, will probably hang on PC110_EVT1_SEC.

Well, I won't be surprised if it also hang on nonsec version because I messed up something. :D

base address (upload address) of this is 0xD0020000, this can be also tried to write into mmc card.

It's endless loop of filling UART0, UART1, UART2 FIFO TX queue, so something should appear if it wont hang and if any of UART port is configured. Tommorow I'll upload version with configuration of all uart ports from scratch (GPIO and clocks settings)
[Captivate Android Development] midas5:
Does this include the source code! If it does i could help out.
[Captivate Android Development] midas5:
Don't worry about the SECKEY. The phone does not use it. So there is no need to worry about signing the bootloader or any trust chain.

It just uses a simple check sum.
[Captivate Android Development] Rebellos:
In Adam's log there is "Secure Fail Error", which can occur only when SECKEY is non-zero. Am I wrong?

compile it using fasm_arm, If ya wish add modifications including uart clock settings and gpio configuration, so it won't reign on configuration by iROM.
[Captivate Android Development] AdamOutler:
It kinda looks like marketing for Samsung's trust model... Just about every error reverts to Secure Fail Error.

I tried the V2 and Secure Fail Error'd.

This phone's UART logs display NON Secure boot version... It's the 3rd one I've brought back from the dead with JTAG. However this one does not display anything on typical 619Kohm UART whatsoever... this leads me to believe that something may be going on with it. I'll test with the next device which comes my way.
[Captivate Android Development] AdamOutler:
I believe Odin does something to the bootloader when it goes through Loki... It's likely that it gets signed or something. This would explain why you can't just dd a bootloader and reflash with odin. The file DOES get modified in some way.

I'll try the bml12.
[Captivate Android Development] DaNaRkI:
Getting Props on the XDA portal and twitter. If that doesn't get more ppl on this then there is something wrong with the community.
[Captivate Android Development] midas5:
Odin does not sign anything.

All that happens is that the first 0x1000 bytes to boot.bin get dropped and it just shifts the rest round a bit. That is why the dd fails because the first 0x1000 bytes of it get dropped.

I think we might have some more work to do on this. My guess is that the checksum is being done wrong. Also the header might be wrong. On the uart boot the header is 4 bytes and you cannot tell it where to load and run. It will always run from ...20000

I will have to look into the usb bootloader code in the irom further. I might then be able to fix the hello world program.
[Captivate Android Development] Rrryan2:
+1. Congrats on the portal mention too!

Wasn't being completely facetious when I mentioned it before either, but where the hell is Samsung John when you actually need him? Seriously.
[Captivate Android Development] PseudoChris:
The "Unbrickable" Challenge!

The grand prize is a free trip to Samsung for your phone (shipping and handling charges may apply) as I would doubt that in the off-chance you are able to brick the phone.. they might not even know what to do with it.

Although, the classic drunk-drop in the toilet will likely still do the brick-trick for any phone. :p

But I do enjoy some extra room for play. I may have to unlock one of these and use it as a backup.

Impressive post! Thanks for the info.
[Captivate Android Development] xijar:
Very impressive work. Will definitely do the mod once I see some firmware. I can't tell you how much I appreciate this community.

Sent from my i897 running MIUI 1.8.12 with TalonMTD kernel.
[Captivate Android Development] Nitro_123:
Awesome... as a result of this project, can we dual-boot from the internal memory like a WP7/Android dual boot?? or maybe iOs :P

Wishing the devs all the best out there!!
[Captivate Android Development] AdamOutler:
I guess I'll offer some incentive as well...

1 free, new, official SGH-i897 battery for the first person to get some firmware operating on a Captivate using this method.
[Captivate Android Development] AdamOutler:
So are you saying that we can just DD the PBL and write 1000 junk bytes in front of it to make it a valid partition?
[Captivate Android Development] midas5:
I don't know for sure. It could be worth a try.
[Captivate Android Development] midas5:
Just thought I would add a caveat to the "Unbrickable".

There is a way to brick the phone so that even Samsung cannot recover it.

If we were to accidentally write the the SECURE KEY area, the IROM would then expect a properly signed boot loader and requires the chain of trust.

The problem being is that if we write a random byte to the SECURE KEY area, setting it to something other than 0, we will not have the private key needed to sign the bootloader and thus be stuck.

So, we have to be really careful when writing to any address in case it is the SECURE KEY area.

According to the Samsung manual, even a RIFF box will not help in that situation, because is also puts the JTAG into a secure mode requiring the same signed code, so the RIFF box would not be able to communicate over JTAG.
[Captivate Android Development] midas5:
Not yet. We are working on it though.

We need to write our own bootloader.
[Captivate Android Development] votum:
That made me laugh, I dropped my phone in a toilet a few weeks back. Sucker didn't even turn off, my power button stopped working for a few hours, so I had to pull the battery and reboot to check my messages or use the phone but once it dried out it was just fine.

Never had a phone prolonged to water though, but I;ve dropped a few in for a few seconds and a day or two to dry worked on all.

Excellent work by the way OP!
[Captivate Android Development] connexion2005:
I have not worked on one that had this mod performed. I'm not sure if it affects JTAG in any way but I'll report back once I know. My worry is that the board needs to be able to be reset for JTAG access and I'm not sure of what state it's in when it becomes this KIT. I feel like I had an i9000 board from a while back that was in a similar state and I couldn't connect via JTAG due to it but the scenario was different. It would only show itself to the machine for 3 seconds at a time and release.
[Captivate Android Development] midas5:
This mod should have no affect on jtag.
[Captivate Android Development] connexion2005:
Like I said, you'd be surprised what can get in the way of JTAG interfacing. I don't think it would either but I'd be far from surprised if it did.
[Captivate Android Development] AdamOutler:
I just recovered my phone where all the JTAG points were missing.

�1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------

+n1stVPN 2688
+nPgsPerBlk 64
PBL found bootable SBL: Partition(3).

Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Non Secure Boot Version.

This is the USB UART output from the hard brick which I was testing with the code provided earlier. Oddly I cannot seem to get it to say OM= anymore.... Could be a different PBL.. dunno... I know it's got the OM5 Mod performed correctly because I can see the UART output.

This phone was also missing every jtag pad... I had to connect JTAG to the small blue points at the ends of the pad...

Anyways.. I'm planning on routing the little dot for the UART (top right pad in the pic) to the outside of my phone and making a clip-on point by melting a piece of solid core wire into the case of my phone. This way I can monitor JTAG uart without opening the phone up... This will make testing much quicker.

Any ideas on why the OM=0x29 isn't showing up on this phone? That kinda bothers me.

Also,

+n1stVPN 2688
+nPgsPerBlk 64

does this provide some sort of reference where the file should go in memory? what is n1stVPN?
[Captivate Android Development] midas5:
No om output is probably just the pbl version or some debug setting not set. I don't know for sure.
[Captivate Android Development] AdamOutler:
Well, I busted off my JTAG UART points, including the Vias at the ends of the pads...

So...... I went and found more...

Then I made them accessible from the outside of the phone
[Captivate Android Development] Smasher816:
Great work adam.

Nice job on finding extra JTAG ports and making them accessable from the outside.

So did you actually reflash the bootloaders from a hard brick using this?
[Captivate Android Development] connexion2005:
Cool deal I hadn't come across one just yet. Glad you learned that trick of the trade to connect to the needle point legs of the JTAG controller. As long as you can expose them with a fiberglass pen, a light scraping of a razor blade and some PCB solvent or cleaner, you have a chance to connect. I've repaired a few boards that were fried by customers who thought they would be able to JTAG the Captivate by connecting to the points them selves with no pads available... ;)
[Captivate Android Development] AdamOutler:
I've been working at component level and rewiring circuit boards for 12 years. Back when I was an Army radar repairer it was my job to get things working at all costs.. So, sometimes I'd have to short, bypass, jumper and fake signals on any of the 120 circuit boards on the radar so it could track mortar/artillery rounds. General's asking why his radar is down(because there's an inch of sand covering the circuit boards) and helicoptering parts out to get the sucker up right away.

There's no pressure when working on cell phones so it's kinda just a matter of taking some time on it.... It's almost enjoyable.
[Captivate Android Development] FirstNoobToBrickHisPhone:
You can only do this with the Captivate?

Because so far I've only seen Captivate users doing this.
[Captivate Android Development] AdamOutler:
Its possible to do this exact same mod to several phones including all in SGS lineup, all bada, most Samsung Windows Phones and even iPhone. This is a very popular processor.

Just gotta figure out the resistors. To be sure you'd have to remove the processor from a test board.
[Captivate Android Development] AdamOutler:
bada wave s8500... it's one of these resistors

now.... on an iPhone4 look at the top right corner of the processor and see these 6 resistors in line.... Those would be the OM resistors

and for captivate:
[Captivate Android Development] AdamOutler:
in locating bootloaders... this is very important

<6>[ 0.000000] Initializing cgroup subsys cpu
<5>[ 0.000000] Linux version 2.6.32.9 (jetaek.lee@sep-11) (gcc version 4.4.1 (Sourcery G++ Lite 2009q3-67) ) #1 Tue Sep 21 19:12:29 KST 2010
<4>[ 0.000000] CPU: ARMv7 Processor [412fc082] revision 2 (ARMv7), cr=10c53c7f
<4>[ 0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
<4>[ 0.000000] Machine: SMDKC110
[Captivate Android Development] madmattco:
just a thought here, but probably already been covered or thought of, but in my old days of htc hardware, i remember a version of mtty that would allow you to shadow a usb connection and see all data being passed to and from the phone with the computer. would it help if we loaded a bootloader with odin and watched what went on?
[Captivate Android Development] madmattco:
wow. i just looked at my sig. seems its been awhile. such fond memories
[Captivate Android Development] AdamOutler:
No tenchar
[Captivate Android Development] UberPinguin:
WOW, Adam. That is some truly astounding work. I cannot wait to see what comes of it!
[Captivate Android Development] xHausx:
Well done man, this is truly impressive. If you ever get bored you should consider picking up a msm8660 device to work on. :)
[Captivate Android Development] Rebellos:
S5PC110_EVT1_UM page 1955

also in S5PC100_UM_REV101, page 1831 all SECKEY SFRs are Read-only

The same manual, table on page 1829 states that secureJTAG area is SW accessible and SECKEY is inaccessible, altough it havent been precised is it R-only or R/W.

It havent been clearly stated that SECKEY can be written from code level. Or at least I hadn't found any info. Please tell me where did you read it.

These info can be fake. Only CPU info (2 lines starting from CPU) is deriven straight from CPU ID SFR. The rest is hardcoded and can be misleading (for example alot of SGS kernels shows SMDKC110, while it's in fact ARIES, badadroid, depending on version is SMDKC110, ARIES or SMDHC110, when its WAVE, or whatever codename is)

My theory, that would fit it all, is that most of SGS and similiar bootloaders are mean to non-secure boot, but all of these are signed when released, in case they are run on EVT1_SEC revision, but IBL doesn't continue secure booting, doesn't check PBL integrity and just loads it, ignoring secure-boot. That doesn't mean all bootloaders are done this way, because we have already seen logs with iROM e-fused Secure Boot.

Another theory is that iROM code isn't the same on all s5pc110 hw revisions, and yours shows Secure Fail Error in another cases than nonzero SECKEY and integrity check error.

midas5, can you confirm my analyze? Here it is:

Using IDA 6.1 (does much better ARM disassembly than 5.x)

I've marked errorcodes in function D0007EF4 print_error (I called it this way), here we have

ERROR_SECURE_FAIL EQU 0x46

Then I'm using Search->Immediate Value, typing 0x46 and ticking "Find all Occurencies", here are all occurences that fits

1) R6 is bool secureboot equals to 0 or 1 (it is being set at the beggining of iROM execution, depending if SECKEY SFR is set)

in this place we fall after uart/usb boot

2) This one is called when variable holding ibl loading result isn't 0x12345678 AND R6 != 0

Please note that function names are my guesses, in fact compare_rsa_checksum is for sure using SHA1 algorithm (found hashing functions in code), not sure about RSA yet (based info about RSA on usermanual)

Thanks in advance for checking and pointing my errors out.
[Captivate Android Development] midas5:
From my reading of the code, if the phone is in non secure boot mode, it will try a simple checksum, if the checksum fails it tries secure boot mode anyway. So as long as we can get the checksum right, we should be ok. I would have to check, but i think sending all zeros for the code should probably pass the checksum test. Won't actually run anything useful but will get us closer to an answer.
[Captivate Android Development] AdamOutler:
Very good information for testing validity.... what would be the failure at this point? Still Secure Fail after it tries and fails to read the code? Or would it error out from all zeros and lock?
[Captivate Android Development] midas5:
The aim is to get the 0xBB back from the phone, meaning that the checksum worked.
[Captivate Android Development] AdamOutler:
right! Ok, that makes total sense.

I'll report back with UART results tonight.
[Captivate Android Development] Rebellos:
That makes sense, except the one thing :(

D0008640 start_uart_booting is

__fastcall ERRCODE start_uart_booting(int uart_port, int baud_divisor, int code_start, int size_limit)

called only this way

ERRCODE ret = start_uart_booting(2, 0x23, 0xD0020000, 0x15400);

if(ret != 0)

print_error(ret);

there are 3 jumps and one straight instruction route to return of start_uart_booting which is under 0xD0008698

instruction route:

1 jump:

2 jump:

3 jump:

(i changed now addr ibl_status_reg to irom_status_structure in my IDA file - fits better)

So in case when xOM5 = 1 if you don't see anything from below (assuming that iROM output is monitored) and you see some 0xAA (sent over 300ms most likely), its sure that iROM downloaded something from UART and tries to boot it immediately if SECKEY is null, or tries to validate it first if SECKEY is not-null.

(in case there is no respond for 0xAA, send_ping_recv_pong(byte) tries during 300ms (300 is passed as parameter for timer function, so it can be nanoseconds tbh) sending passed byte all the time, until timeout or gets the same byte in RX buffer)

(when 16bit checksum calculated during receiving doesn't match checksum received from DNW)

(when it gets first int, which is size, bigger than 0x15400) //thanks for midas5 for clarifying
[Captivate Android Development] midas5:
The first 4 bytes sent over the uart, after the AA and CC handshake, are a 32bit unsigned integer.

So, if we let "value" be this 32bit integer.

If (value > 0x15400) printf("Uart Data Length Over");

So, before when Adam was sending CC for these first 4 bytes, the 32bit integer " value" would have been 0xCCCCCCCC

0xCCCCCCCC > 0x15400 so you see "Uart Data Length Over" message.

It is not when the amount of bytes send gets greater than 0x15400.
[Captivate Android Development] Rebellos:
Okay, analyzed few SBLs, and got bad news, which denies my previous researchs about SEC and NONSEC HW versions, now it looks like most of S5PC110 (maybe even all) have got SECKEY notnull (at least offset 0x18 in SECKEY), there is a proof:

There is similiar IF statement in all SBL I've met:

The strings are different in various SBL

Sometimes in "else" case there is only

In others there are

iROM is basing on the same SFR (0xE0E00018) when deciding if its secureboot or not.

If you ask Google about these strings printed by SBL, "IROM non e-fused version." doesn't appear more than few times, only in our discussions, no hits in uart boot logs. Here comes conclusion - not e-fused version (with fully null SECKEY SFR) of S5PC110 doesn't appear in handsets, if CPU is e-fused that means it does support secureboot, and iROM does start secureboot by integrity checking of IBL, but IBL doesn't continue it, it switches to non-secure boot (ain't sure about logs with debug string "iROM e-fused - Secure Boot", maybe there exists IBL+PBL+SBL combinations which support secure booting, but it must be given up on SBL stage anyway, or anybody had seen signed kernel image? ;d or its just meaningless debug string)

So in Samsung's language:

E-fuse - containing secure key with ability to secure boot

Secure boot - integrity checking on every bootloader stage, so it allows only signed and not modified code

I've been previous reading only few bytes from 0xE0E00000, thats why I thought there exists NONSEC versions. Sorry for leading into mistake because of that.

I'm checking if signing mechanism can be taken from uboot for odroid, if yes - expect more, signed this time, test versions soon.

Adam, please don't damage your testboard in the meantime. ;D
[Captivate Android Development] AdamOutler:
No problem. As far as I can tell from the processor manual, UART and SDCard boot are two methods which bypass security checks from IROM....

The efuse can be written blank. This may be the case. It can only be written once and it can never be modified again

If we were dealing with a signed bootloader, then why the heck does Samsung not sign them per phone so they can't be mismatched?

As for damaging the board... I moved JTAG UART to an external connection, so my device is safe.
[Captivate Android Development] Rebellos:
Sorry, they don't.

I don't know. They do many weird things, with no logical answer "why" (experience from bada things reversing)

But they released software for signing, or rather e-fusing (thats probably the difference also, my mistake) and I'll have fused testcode today. :)