yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] androcheck:
Hi!

I was diving into this thread yesterday and am following your thinking paths closely since then! Nice work, I am really excited! :)

Yes, I see it the same way.

It even hasn't to be exactly 0x29. As already outlined by TheBeano it seems that every OM value from 0x20 to 0x2F will result in register r8 be set to 0x10 (which should result in UART boot).

The two compare operations at d0005a94 and d0005a9c jump to the "om setting error" label if the (shifted) value is less-or-equal than 0x0f (00001111) or greater-or-equal than 0x18 (00011000). For every other value the "default case" in d0005aa4 sets register r8 to 0x10.

So in other words, before the shifting takes place this would mean that every value for OP:

0010 0000 <= OP <= 0010 1111

would do the trick.

And this perfectly matches the description in Table 6-3 (OM pin settings) of the manual where we see that only the two pins OM[5] and OM[4] need to be 1 and 0 (to boot from UART first).

So that confirms what we saw already in the manual.

The missing link:

So if I understand this correctly, we are missing the following information:

How can we trick the phone to get the pins OM[5] and OM[4] set to these values during power on (if it is possible at all).

The current approaches we have are, trying different resistor values for the FSA9480 USB switch and/or pressing some buttons during power-on. Or is there anything else we can do to influence the initialization?

Did I understand this correctly?
[Hardware Hacking General] js22:
Yeah, that seems to be where we are stuck. The only encouragement is that we know it is possible.
[Hardware Hacking General] TheBeano:
Yes that is a good summary. We are working on the theory that this schematic from the service manual shows a signal going from the FSA9480 BOOT pin to a signal named BOOT_MODE, which in any sane world would go the the chip's OM5 pin. But we don't have the full schematic to prove it, and we don't have the internal details of the FSA9480 to show how that pin gets triggered. You would think it would be the resistors with BOOT_ON in their names (like RID_FM_BOOT_ON_UART), but apparently not.
[Hardware Hacking General] AdamOutler:
There's still lots of untested items.

I know only 7 of these 12 pins are used in jtag.. the rest are unknown.

I took this picture while getting measurements on the jtag port

These pins are used for loading firmware with JTAG method. Possible that jumpering one of these may set the signals we require?
[Hardware Hacking General] midas5:
Would getting the phone into a mode that displays this [see attachment] help to maybe get OM[5] set?

One method to get there, is do a heimdall dump and press CTRL-C half way through. NOTE: You need the 301k jig to undo it so do not try until you have the jig.
[Hardware Hacking General] midas5:
Other ideas to look into (used on other chip types, so might not work here.):

1)

"The UART interface is capable of resetting the chip upon reception of a break signal. A break is identified by a continuous logic low (0V) on the UART_RX terminal."

I.e, trying to send a break signal to the UART at power on might help.

2)

"I could not get the bootloader to connect without adding an external pull-up on USB_DP."

I.e. A resistor on the USB_DP pin to pull it up to 3.3V
[Hardware Hacking General] midas5:
Yes, getting FSA9480 BOOT_MODE set should do the job. OM5 is labeled "Boot Mode" after all.

The FSA9280A.PDF mentions a "Factory Mode", but unfortunately does not include the pages on how to get into factory mode.

It does mention "Detects Factory Mode Cables".

I expect it might be a un-documented resistor value.

The FSA9280A.PDF lists:

Accessories:

Headsets

(Headphone/MIC/Remote)

USB Data Port

Accessory Detection

UART Serial Link

USB Chargers (Car-Kit, CDP, DCP)

Factory-Mode

TTY Converter

Of which, factory-mode looks the most useful.
[Hardware Hacking General] TheBeano:
Once that is on the screen you are already in the secondary bootloader, which is complaining that it can't load the operating system. If the CPU boot mode was triggered you wouldn't see anything on the screen. I guess the bootloaders could have some code to go back to the CPU's recovery mode, but that wouldn't really help us for the problem we're trying to solve, which is a bricked phone that doesn't have working bootloaders.
[Hardware Hacking General] zianna123:
3,579545 MHz 9600bps

7,3728 MHz 19200bps

10,245 MHz 28800bps

some work at 28800 but almost any work at 19200 (99%).

wait did you say10hz??? nothing runs that slow?
[Hardware Hacking General] AdamOutler:
I can get a string of KZKZKZKZKZKZKZT... about 4 times at 115200kbps during the AT&T woosh (after kernel loads), however with a high impedance probe, it is simply 10hz as read by two qualified technicians with 60 years of combined electronics experience and an oscilliscope working together at my shop.
[Hardware Hacking General] zianna123:
just doesnt seem right, at about that point it should be reading the Ki and imsi

then checking to see if you can register with the tower. but then again i havnt touched a cell sim card sinc 2001.. ppv and satalite :) now there we had some fun.. but anouther story.

we still band from Irdeto land <damn feds>
[Hardware Hacking General] midas5:
That looks to me that you are probing the RESET pin and not the DATA pin
[Hardware Hacking General] AdamOutler:
I was probing the two pins which I determined earlier to be clock and data. Clock was regular up/down 10hz, data went

/--|____|___|____|--\ .... that's a START command, 2 HIGHS and a STOP command in i2c format at 10hz.

I'll post the videos correctly later... looks like something happened to the data line vid. I'm pretty sure I got it right though. It is 10 hz on high impedance 115200 with a active low on the pins...

the two pins are the X's in this stupid ascii art...

/top of phone\
---------------
| | X

| | X
---------------
\Bottom of phone/
[Hardware Hacking General] radekgers:
If the device identifies itself on USB as a Samsung test board why do you want to speak to it through arduino UART? that doesn't make ANY sense. If it identifies itself on USB then that means that there is USB running and it can receive data on USB, probably through virtual serial port, but NOT uart.

I don't know why AdamOutler got so fixed on uart and i2c. Those are low level protocols. irom has a full support for USB and there is hardware usb port on the chip. Using uart to upload anything would be stupid of Samsung engineers.
[Hardware Hacking General] radekgers:
antsm:

Try this usb driver for your VID/PID, it should work.

If it works, use the DNW.exe utility (attached), from menu choose USB Port -> Transmit and... choose a file for transmission... don't know what yet, maybe some bootloader ;-)

Anyways, I'm not sure of any of that but I think it's worth a try.
[Hardware Hacking General] AdamOutler:
We think it is a hidden protocol. The IROM can identify itself but has no USB capability. Check out the IROM code in The GalaxyS Hack Pack for more information. I'm not good at reading it, but it's not large enough to support a set of USB download commands like the SBL is... However, UART can revel much about the phone and the IROM contains UART download mode code.

The IROM DOES have a message which states insert OTG cable.. But we cannot find anything that supports USB OTG in the IROM.... The Development kit comes with a board which does USB to UART conversion. We are trying to recreate this functionality on the end product.

Again, I cannot read teh ARM Assembly... I am only repeating what I have read through the 59 pages of this thread... Check out the GalaxyS Hack Pack for the disassembled and annotated IROM code. http://xdaforums.com/showthread.php?p=14463797
[Hardware Hacking General] radekgers:
According to this S5PC110 Development board:

http://www.armdesigner.com/xsms/html37/uploadfile/20100707120620748.pdf

the usb->uart development board is used only to trigger the download mode in a fully booting system. After that a normal USB cable is connected for transmitting data.

IF the device already identifies itself like that it looks like it's already in download mode and waiting for usb transmission...
[Hardware Hacking General] midas5:
You can write perfectly good USB driver code in about 2K Bytes. The IROM could easily support download of a file via USB.
[Hardware Hacking General] zianna123:
at this point i wouldnt rule out either as a possibility

the usb stack is definatly there, and enuff of it to accept a file. aswell as uart.

i2c would be my last resort. as u just dont know the id's of the devices you are trying to reach, and even then to send any sort of file to it over i2c would be a challange.

i2c is good for intercircuit chat and status updates to poll various gpios, but its not a means to flash.

and i would agree, a total flash of a device, would be +- 200megs.. over uart? samsung would be mad to think that. my gues is still uart low level ibl first stage, then kick into usb mode

from all the modes i have tested, there is one common theme .. it starts uart.. pause for around 100ms then brings up usb.. then uart dies

DRV_Get_Boot_Bin: completed!

1

2

4

DRV_modem_reset: completed!

DRV_Send_ModemBootloader

receive byte from CP

CP send response

AP send PSI binary

CP CRC checking OK

receive byte from CP: 0x1

CP PSI branch OK

DRV_Wait_ModemInit!!!!!!!!!!!!!!!!!

Modem boot in UPLOAD mode..DRV_Setting_ModemUploadMode!!!!!!!!!!!!!!!!!

DRV_Modem_BootingStart

new usb_upload()

usb_power_start()

i want to test DNW in this mode, as loke isnt there odin is out.. maybe with DNW, i can see something more
[Hardware Hacking General] radekgers:
I think DNW needs those drivers I attached to work, so your device must identify over usb as VID 04E8 PID 1234 or PID 6400. Samsung test board. Otherwise DNW won't work. I think.

One more thing... when we enter standard 3-button download mode (odin) in Windows we get 2 devices. Samsung USB composite and Mobile Modem... so... Odin download mode also goes through the CP? (modem)
[Hardware Hacking General] midas5:
Odin uses only USB to do its task. Heimdall does the same job as ODIN and Heimdall is open source so you can see exactly what it does.

The I9000 IROM supports USB ID 04E8:1234 so DNW will probably work with it.
[Hardware Hacking General] radekgers:
Yes, DNW should work... I've done that with an Mio P550 palmtop a few years ago with an older Samsung processor, it identified as SEC S3C2410X Test B/D. DNW flashed it with no problems :-)
[Hardware Hacking General] antsm:
I've figured out that SEC S5PC110 Test B/D device stay in system only for ~5 sec (after USB was plugged) and then disappear.

radekgers,

I tried to use DWL from AdamOutler archive (it's a bit newer: 1.01 vs 0.6), driver seems to be installed without any issues, but in those 5 sec when device is alive, DWL anyway reports "Can't open USB device" :(

Hmm...
[Hardware Hacking General] radekgers:
Ah, I thought this device stayed like that for an unlimited time...
[Hardware Hacking General] midas5:
Here is a reference to the protocol used.

It is the correct ISO standard number, but I don't know how good the text it.

http://www.cardwerk.com/smartcards/smartcard_standard_ISO7816-3.aspx

It is not I2C.
[Hardware Hacking General] midas5:
No, It tries OneNAND, if that fails it tries SD card, if that fails it tries USB download, if that fails, it HALTs, i.e goes to branch instruction that just says jump back to me again forever.

I am in the process of going through the IROM dump and verifying that all the comments in the published disassembly are correct. So far so good.

I still have not seen any communications with the SIM or a way to force download communications over USB. I.e. Ensure the OneNAND boot fails.

It would really be nice if the person who has the brick, antsm, could hook up a serial port to it to see some messages. The IROM should be outputting messages like "NO Boot Image" to the UART on Com Port 2.
[Hardware Hacking General] midas5:
Antsm,

What did you actually do to get to this state?

I.e. What did you do to get from a nice working phone to this one with the SEC S5PC110 Test B/D device?
[Hardware Hacking General] antsm:
Tried to read some data from phone using DWN (Upload function), and if you are catch a moment - you take some piece of bytes ;)

But what type of addressation are using in this tool? Is it memory-related addressation or NAND-, or something else? ;)

midas5, i've bricked my phone to achive that ;)

In fact, i'm just flashed bootloader via Odin, regular procedure, but as result i've got a SEC S5PC110 Test B/D device :)

So nothing special from my part.
[Hardware Hacking General] Rebellos:
It tries UART download, not USB download. UART and USB are hidden in one micro-USB, but as far as I know cannot be used in exactly the same time - FSA chip selects USB or UART interface multiplexing.

However, it DOES support USB communication, more or less... rather less, cuz I couldn't find any longer code specific to some transfer protocol - of course may be wrong.

Core of UART download code takes about 1KB or even less, it is possible to put the simple USB download code in comparable amount of code.

At oneDRAM share, about which Adam asked:

CP does share oneDRAM area with AP - its 0x35000000-0x36000000 area (mapped like this in AP on all SGS platforms, it can be also mapped 0x25000000-0x26000000, like in S8500/S8530)

This area is being used as primary RAM by CP - it doesn't appear do have any other RAM memory than 16MB block of oneDRAM, altough I cannot deny that it can access the whole chip - 128MB. Whats bad - first stages of BL from oneNAND are executed in iRAM inside of AP, then execution move to DRAM1 block of AP, while oneDRAM is connected as DRAM0 block. However, I don't know if CP can be connected to DMA bus.

Can you finally confirm, does IBL always persist in oneNAND? Even in totally bricked phone? If yes - BL0 will probably always finish its init process on loading IBL into iRAM and jumping into that...
[Hardware Hacking General] AdamOutler:
In that manual they have access to tthe dips which control booting from OneNAND, Tflash or USB.. We do not. If the IROM contains USB code, then great! It's been said that it does not. Which is why we have a 3-MEGABYTE Secondary Bootloader which handles Download Mode and a smaller IROM which handles UART communications for debugging purposes.

You'll notice in that manual they are loading a kernel, not a bootloader. The bootloader is on a T-Flash card. The T-Flash card is activated because the dip switches are flipped. A Trans Flash card MIGHT work if we can figure out how to get the unit into B/D mode, however we can't reproduce it.

Built into the IROM is boot-from-UART and boot-from-MMC. We can't be sure if we have correctly made a MMC card. However, we know that the very first part of the handshake from the S5PC110 chip is that it will say 0xAA and you're supposed to return that. This is the thing we are trying to do.

After confirmation of 0xAA UART, hack away with the hack pack and create a MMC card.... We just need proof that the IROM can in fact boot from UART.
[Hardware Hacking General] radekgers:
Actually they do update a bootloader: u-boot.bin, after that they update the kernel. They don't have dip switches on that board, t-flash card is the standard method of booting that board. That board does not have any nandflash. The structure of this t-flash is exactly the same as our nand, it's just removable.
[Hardware Hacking General] b4dg3r:
The S5PC110 data sheet (page 6-4 figure 6-2) says that the iROM can boot from USB or UART depending on the state of the OM pins.

I've not seen anything in the iROM dump that would suggest otherwise; theres a lot of USB code in there and at a glance it looks reachable.
[Hardware Hacking General] connexion2005:
This is correct and commonly seen on a phone with incompatible or not fully flashed bootloaders. It's a fail safe mode for the board.
[Hardware Hacking General] Rebellos:
This booting is called in manual "UART->USB" No clue what does they mean though.

Anyway, this code IS reachable when bit OM_REG[5]=1, in our case this bit is zero, was zero, will be zero, null, and you can't change it.
[Hardware Hacking General] b4dg3r:
Without access to the PCB schematics, how do you know that?
[Hardware Hacking General] AdamOutler:
Information came from his cat... See his cat was at the vet when a Samsung employee walked in and mistakenly took him home, then laid out the plans for the phone and went to work.... you see it wasn't until later that he realizes it was someone elses cat... but not before that cat had learned that the XOM0....5 pins are hardwired to vcc and gnd. The XOM pins are documented as inputs to the OM registers... no way to change the registers....

However, the boot order STILL includes UART. UART is last.
[Hardware Hacking General] AdamOutler:
Damaged my SIM card slot.. I won't be able to help for a week or so.. I put three of those replacement sim/flash card shieldson order. Buying 3 new for $5 each with $7 shipping with shipping was a better deal then 1 used on ebay for $18.... They're supposed to arrive in 5-10 business days. If anyone needs a sim card slot, let me know...

I just got my logic analyzer in today That Logic Shrimp you have.... Does it make for clean signals? I am getting ALOT of randomness on my unused lines and on some used ones as well. I can't really see the forest through the trees.
[Hardware Hacking General] TheBeano:
You need to earth any unused lines and make sure the used ones have a good connection to whatever you're monitoring, otherwise they will pick up noise.
[Hardware Hacking General] AdamOutler:
I have good grounds. That makes sense about grounding unused. I thought the "filter noise" option would take care of transient noise.... Now what does that option do? I guess I have a lot of reading to do on this thing to be able to maximize its potential. I didn't see that in the videos, people just went right at it and skipped that part.
[Hardware Hacking General] midas5:
Well, you would need an OTG wired cable then.

OTG is defined as the following:

1) Powered by the device. I.e. Powered by the Phone, so don't connect 5V to pin 0.

2) Pin 4 shorted to pin 5.

3) Pin 2 and 3 normal for the USB data signal.

I have not checked the IROM code yet as to whether the IROM checks that a real OTG cable has been attached or not.

A PC USB interface cannot be connected to the Phone USB interface if the phone is in OTG mode, so I think using USB for the download might be rather difficult at this stage.

I think using the SD card is a good option for boot.
[Hardware Hacking General] midas5:
I can only confirm that with my I9000 phone, and Heimdall, The IBL is never touched.

Only the PBL and SBL are touched.

This used md5sum to verify it.

I.e. At what offset did bml1.dump match boot.bin?

Further analysis shows:

0 - 0xfff in boot.bin is not used. (Don't know what that is)

0x1000 - 0x3fff in boot.bin is placed at 0x0 - 0x2fff in bml1 (Probably the IBL)

0x4000 - end in boot.bin is placed at 0x4000 - end in bml1 (Probably the PBL)

I can only assume that 0 - 0xfff in boot.bin is some sort of code only used by the flasher (SBL) and not actually written to the flash.

Alternatively, it might be some bug in heimdall.

Can anyone confirm the above further analysis if they have used ODIN? I never use ODIN because I am on Linux.

I will have to look at the IROM code more to see how much of BML1 the IROM loads into RAM and how it does it checksums.

The IROM might load both the IBL and the PBL into RAM and checksum both of them, and start exec at the start of the IBL code.

This would explain why a faulty PBL causes the IROM to fail boot from onenand.
[Hardware Hacking General] midas5:
Has anyone worked out what the first 16 bytes of boot.bin are for.

E.g.

00000800

d00205a0

00025e55

00000260

My guesses so far, not found the answer in the IROM code yet.

00000800; Length of IBL

d00205a0; Load to this location.

00025e55; Length of IBL + PBL (Maybe length of bytes to checksum)

00000260; A Checksum

All these numbers are different on different boot loaders.
[Hardware Hacking General] Rebellos:
0x0-0xfff of boot.bin contains one, small bootloader stage (ends around 0x600)

which begins with 4 magics (it has probably something to do with e-fuse info, note that while first 2 are like indeed 4byte, the another 2 may be single or 2byte values)

DCD 0x800

DCD 0xD00205A0

DCD 0x25E55

DCD 0x260

this code doesn't LOAD anything, it reads SECKEY and do some short routine, havent got time to analyze it, but I assume it may be some decryption proc/or just setting e-fuse boot_info. (in case of non-safe boot I think it is totally skipped) After doing such routines it jumps out to another BL stage in iRAM

0x1000 is another bootloader (most likely IBL)

begins with 4 magics too

DCD 0xA00

DCD 0xD002052C

DCD 0x23432

DCD 0x2D4

It is also very tiny. Ends near 0x1600.

Does not load anything from oneNAND, but does NOT read SECKEY, looks like it does not much more than reading RST_STAT register (reason of boot), storing it in iRAM and jumping out to another BL stage in iRAM.

Under 0x2000 we've got one more BL - no magics at the beggining, it is little bit longer than the previous ones but ends near 0x2800.

This is in fact IBL, it initialize RAM controllers, setup memory mapping, setup system, few clocks and then loads PBL from oneNAND to DRAM (not iRAM anymore) and jumps out to PBL.

Notice the UART2 line reset before launching PBL.

Then we've got empty area to the 0x4000 - where the PBL starts.

//edit1

Oh midas, havent noticed your last post.

What do you mean that ALL these numbers differs in each version? First two also? ;o

//edit2

I don't think PBL is loaded by BL0 - it is clearly loaded by IBL.
[Hardware Hacking General] midas5:
Did you get that 0 - 0xfff of the boot.bin is not used. It is not written to onenand, so therefore not used during boot.
[Hardware Hacking General] midas5:
What I meant was the magic numbers are different at offset 0x0 and offset 0x1000

I expect that we might be able to do a

dd if=/dev/block/bml1 of=bml1.dump

Then dd bml1.dump to an external sd card.

Plug the sdcard into a bricked phone.

Boot with the 619K resistor, and see if the bricked phone outputs any PBL messages. I.e. It managed to boot from sd card.
[Hardware Hacking General] AdamOutler:
I was reading in the processor manual that there is some sort of pass-through setup when the processor goes into any of the many sleep states... it always runs part of IROM, pbl and sbl to verify that they are in memory and sane. It then jumps back into the instructions that it was executing.... I don't really understand how this works, but it seems like it has potential for hacking... it basically bypasses the entire bootloaders and executes instructions contained within once they are in memory.
[Hardware Hacking General] AdamOutler:
Let's get terminology straight here....

OneNAND-smaller internal memory. Its fast

SDcard-moviNAND also internal which is basically a 16gig SDcard soldered to the board. Its slow.

MMC-external SD. Its slow but removable.
[Hardware Hacking General] midas5:
I was talking about copying the bml1 dump to the MMC -external SD
[Hardware Hacking General] TheBeano:
This is outputting the "1" character that you see in the boot logs just before the PBL output starts.
[Hardware Hacking General] AdamOutler:
I was talking about posting these videos earlier.... This is the CLK and IO pins on a Samsung Captivate without a SIMcard inserted, as viewed on an oscilloscope.

These signals were recorded at the ROM spalsh video. I paused it for careful analysis. The video shows manual review of the signals

Pin 6- IO- 1V/50miliseconds per divide - High Impedance 1x probe

[YOUTUBE]D6Q-dGNUQkk[/YOUTUBE]

Pin 3- IO- 1V/50miliseconds per divide - High Impedance 1x probe

[YOUTUBE]DZOSHCKFt-A[/YOUTUBE]
[Hardware Hacking General] midas5:
Is this the sim card interface or the sd card interface?

If you are trying to do useful stuff with sim interface, at least read the spec i posted, with specific notice taken on how to get ATR from the sim.

Once you can sniff the phone getting ATR from the sim, you will be in a better position.