yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] AdamOutler:
yeah... i think it was autocorrect. I had added the word SDcard on an edit from my phone and it changed SIMcard. I'm working on bus-pirating the JTAG now that my SIM card slot is broken.
[Hardware Hacking General] midas5:
You can get small PCBs that are layed out as if they are a sim card, but just have wires coming from them. You slot them into the sim card slot, and make the connection without soldering anything.

I use them for debugging purposes when writing applications that load onto smart cards.
[Hardware Hacking General] juicyhusk:
my issue may be connected to this thread, pleas read!

http://xdaforums.com/showthread.php?p=14669050#post14669050
[Hardware Hacking General] AdamOutler:
Ok. So you have a brick. What tools do you have for testing or restoration? Id like totaled a crack at it. Im working on JTAG with OpenOCD and Bus Pirate now. I would like to see the UART output and what happens on your sim card slot. If you'd like, it could go a long way towards helping us to understand the solution.

Midas5, I can't find that SIM pcb you spoke of. I am finding sim card breakouts.. I may have to make one with conductive ink or something.
[Hardware Hacking General] AdamOutler:
I was reading and I thought I'd mention this..

http://www.arm.com/products/system-ip/debug-trace/coresight-soc-components/serial-wire-debug.php

SWDIO SWCLK Coresight.... 2 wires.... extra JTAG pins can be switched to other uses when in SWD mode

It's time to look at SWD (Serial Wire Debug). Target speeds are 100kbps and 400kbps.
[Hardware Hacking General] ntfreak:
This core does not support swd - jtag only.

Cheers

Spen
[Hardware Hacking General] AdamOutler:
Page 491 of the processor manual shows the serial wire debug line

http://xdaforums.com/showthread.php?t=1111866
[Hardware Hacking General] AdamOutler:
I couldn't find any 6 pin sim cards.... then I realized mine was actually 8 pin form factor but 2 pins are missing.... I realized this after I made my DIY sim card breakout with razor blade cardboard and copper tape.
[Hardware Hacking General] ntfreak:
Page 487 states that it only supports jtag.

Spen
[Hardware Hacking General] AdamOutler:
Hrm.. well... any idea what pin 12 could be? It's not regulated 5V. I had assumed it might be some sort of switch before you said that.

Here's the JTAG pinout which I've identified so far.

1-3v
2-JTAG TRST
3-JTAG TDI
4-JTAG TMS
5-JTAG TCK
6-UART TX
7-UART RX
8-GROUND
9-JTAG NRST
10-JTAG TDO
11-OPEN. NOT CONNECTED
12-4.3v????
[Hardware Hacking General] AdamOutler:
I got a SIM port capture based on the pinout here: http://i1098.photobucket.com/albums/g374/adamoutler/2011-05-27165223renamed.jpg
[Hardware Hacking General] AdamOutler:
This was captured at 10,000hz.

Pin1 VCC = HIGH

Pin2 RST = HIGH at the time IO and VPP start transmitting

Pin3 CLK = HIGH/LOW @ (I didn't actually measure) it looks like 3khz

Ground = ground

PIn5 VPP (programming voltage) unknown frequency definately data. possibly 9700bps?

Pin6 IO = (I/O data) unknown frequency... possibly 115200bps?

Anyone care to elaborate?
[Hardware Hacking General] midas5:
At a sampling frequency of 10,000 you will not get accurate readings of the CLK, so no point in looking at that. In fact, you will not get any accurate readings of anything over 5 000hz (actually less that 5000, ask Nyquist).

You need to be sampling at over 19200 Hz to measure 9600 baud signal.

It would be nice to decode the data on VPP and IO.

Look for the ATR response that the sim card should give due to the change in state of the RST pin.
[Hardware Hacking General] AdamOutler:
Yeah. I know the rule of capturing signals... However, the OpenBench Logic Analyzer software requires that the stream be the same or close to the bitrate so that it can act as a UART device after the capture is completed. I was reading the manual step by step... In order to decode the streams it has to be recorded at or near the proper BPS. We're looking for 9700. 10,000 is the closest.

I might do some more work on this over the weekend... however, I do believe I will wait for my NDA(Non-Disclosure Agreement) to go through for the bootloader code. If anyone else would like to file an NDA, speak to SamsungJohn on twitter... This would allow us to work together, securely. I will need to see the terms of service on the NDA, but I think we should be able to come up with something and then write a program to interface it as long as we don't give the secrets away...
[Hardware Hacking General] midas5:
How about capturing at the highest rate you can. Save the capture to a file. Sending me the captured file with the software so i can view the file myself?
[Hardware Hacking General] AdamOutler:
Ok in the future I'll post the capture logs... You can download the appropriate package here http://www.gadgetfactory.net/logicsniffer/index.php?n=LogicSniffer.Download I'm using firmware 3.08

My dev phone still has a damaged SIM port. I'm expecting to get 3 new ports within a week or so. I try to keep experimentation on my daily phone to a minimum, regardless of how safe it is... The log above was captured from my daily phone.

It's not easy to obtain a good log. The Logic Sniffer has 24K of internal memory. This equates to a few milliseconds of operation. Using compression I can extend the "dead air" time out quite a bit, but it reduces the available memory by 1/2. Higher sample rates means lower capture times. I can go up to 200MHZ, but that means I get only a few microseconds. Then you add in the random glitch from proximity of the power supply in my computer..... In order to obtain the log above it took nearly 20 reboots of the phone.

But I'm expecting a brick to come in today and possibly some new JTAG connectors as well. So, I may be able to get something tonight for you.

I'm working on a new app... Heimdall One Click. It's rough right now, but I'm making progress and I think it will become the new standard of flashing ROMs. Heimdall doesn't brick phones as much as Odin3. This is going to pull me kinda thin.
[Hardware Hacking General] midas5:
Shame the Logic sniffer does not have more memory. Sort of makes a 200Mhz sampling capability useless. I might look at getting the Mega2560 doing capture. It also does not have much RAM, but at least the USB interface can be reprogrammed to output stuff faster than com port speeds.

Regarding the Heimdall One click.

I have a wish list for it.

1) Run it with a command line switch that causes it to discover which PIT file is actually on the phone, without writing a new one. It would come back saying "You have PIT 512 already installed on the phone"

2) Let it use the same file format as ODIN, but prevent it from writing any boot loaders.

3) Let it use the same file format as ODIN, but only write boot loaders, and not anything else.

4) Have some "safe" mode, whereby it has embedded checksums of the various boot loaders.bin files, and only allows people to write boot loaders that are know not to brick the phone. I.e. Contain a list of known good pairs boot.bin and Sbl.bin files.

5) Somehow prevent anyone from writing I9100 boot loaders to I9000!!!!

With all the testing I have done on the I9000, I now never write any new bootloaders unless I have to. I.e. Boot screen corruption needing the latest bootloaders.

The latest boot loaders in Gingerbread seem the best. So maybe we should only let people install those boot loaders in the "safe mode".

I think something still needs checking. How much is "params" needed by the Sbl.bin.

I.e. If "params" is corrupted, can the Sbl.bin still get into Download mode?

All this talk to heimdall really needs its own thread.
[Hardware Hacking General] AdamOutler:
The Mega2650 runs at 16mhz correct? That would be some slow sampling. However, the memory is larger. You'd need to read on the protocols used by logic analyzer software. It would take some formatting to get it correct, but you could use the bus pirate or generic output methods to transfer data.

edit... i just checked...

Does not look good for Logic Analyzer.... The ATMega is a good chip for interfacing the physical world, but not that great for high speed or ram operations, unless you could convince it to use flash memory for temporary storage.

As for the Heimdall One-Click... The idea is to have it start in safe mode and only flash bootloaders if the user is sure they "want" to do this and that would be a 2 click operation. In this way, the blame is on the user for flashing the bootloaders, or the packager for including the wrong binaries. I'll start a thread in the recognized developers area eventually for help with windows and mac platforms. The idea is to unpack everything, install everything, flash the firmware, done.
[Hardware Hacking General] midas5:
Could we use the USB IDs to identify the phone.

In Download mode, what USB IDs does the I9000 have and what USB IDs does other Samsung phones have?

I think we need a unique way to recognize an I9000 and differentiate it from, for example, an I9000M.

My I9000 in Download mode has ID: 04e8:6601

If different phones have different IDs, we could use that to prevent accidental flashing of boot loaders to the wrong phone. I.e. With USB ID X, only flash bootloaders with this specific md5sum hash.
[Hardware Hacking General] midas5:
I have started a HEIMDALL one-click thread. I suggest all future discussions about it go on there.

http://xdaforums.com/showthread.php?t=1130502
[Hardware Hacking General] midas5:
If it is using compression the sample rate should not really matter.

Normally, compression uses this format.

It detects transitions and time stamps them.

E.g.

At Time X, the state was 1.

At Time Y, the state was 0

etc.

So irrespective of the sample rate, the amount of records will be the same assuming the same amount of transitions from 0 to 1 and visa versa.

It is possible to further compress these values, so size might vary at different rates.

But, I would recommend using compression all the time.

Capturing 12K transitions on one line will be ample.

12*1024 = 12288 bytes.

Assume 63 bit timestamp, with 1 bit for status 0 or 1. (Some systems might have two bits for status, High, Low and Open circuit)

12288 / 8 = 1536 transitions.

Assume 8 data bits, 1 start and 1 stop bit.

1536 / 10 = 153 Characters can be stored since power on in one shot mode. Enough to see the ATR response from the SIM card.

Of course, if it is using RLE compression instead, then that is probably not much use.

The advantage of time stamped transitions is that if there are no transitions, no data is used.

When using RLE compression, even if there are no transitions, periodically RLE data must be stored when it reaches the max length of the RLE encoding.
[Hardware Hacking General] AdamOutler:
I got nothing from the SIM card and the middle battery terminal.

Suggestions?
[Hardware Hacking General] midas5:
What is that stuff before the co ltd. It looks like a different baud rate to me.
[Hardware Hacking General] jutezak:
I think the stuff before the Co., Ltd. is a unicode trade name. Probably Samsung in Korean characters, also known as Hangul.
[Hardware Hacking General] midas5:
On the captivate brick, is it boot looping or are you manually booting it each time?
[Hardware Hacking General] AdamOutler:
It does nothing at all until I hold vol+ and power for 10 seconds. Then it shows me this. Nothing else happens. It acts as though it is off.
[Hardware Hacking General] midas5:
What i mean is the output you posted looks like it has been through the boot cycle a few times. Did it go through a few times on its own, or did you have to press the power button each time?
[Hardware Hacking General] AdamOutler:
No. i held the button, switched to hex and held it a few more times.
[Hardware Hacking General] midas5:
On a normal I9000 phone, we have various usb-ids.

*#7284# Used for switching between PDA and MODEM mode.

Normal USB debugging mode, PDA:

Bus 002 Device 002: ID 04e8:681c Samsung Electronics Co., Ltd Galaxy Portal/Spica Android Phone

Normal USB, not-debugging mode, PDA:

Bus 001 Device 004: ID 04e8:6877 Samsung Electronics Co., Ltd

Normal USB, not-debugging mode, MODEM:

Bus 001 Device 005: ID 1519:0020

Normal USB debugging mode, MODEM:

Bus 001 Device 006: ID 1519:0020 (Has 7 /dev/ttyACM0-6 com ports. )

Phone powered off, in "Charging mode". I.e. Standard "Charging" cable that comes with the device.

Bus 001 Device 008: ID 04e8:681d Samsung Electronics Co., Ltd Galaxy Portal/Spica Android Phone

Special note: This device ID is only present for a very short time before the battery charging animation appears.

Download mode:

Bus 001 Device 019: ID 04e8:6601 Samsung Electronics Co., Ltd Z100 Mobile Phone

Now, is it possible to switch between PDA and MODEM mode on a bricked phone?

If we could find some way to corrupt the IBL/PBL on a bricked phone, we would then get the IROM download over uart/usb mode. Maybe we could get the MODEM code to corrupt the flash.

I think we would only have to corrupt the first few bytes of the flash.

I still have some decompiling to do on the IROM before I can tell for sure if there is any other way to force IROM download over uart/usb mode.

For example, somewhere in the onenand loader code in the IROM there might be a way to cause it to fail. Maybe it checks a keypad value or a resistor value.
[Hardware Hacking General] AdamOutler:
USB mode still works from SBL

SBL> help
Following commands are supported:
* setenv
* saveenv
* printenv
* help
* reset
* boot
* kernel
* format
* open
* close
* erasepart
* eraseall
* loadkernel
* showpart
* addpart
* delpart
* savepart
* nkernel
* nramdisk
* nandread
* nandwrite
* usb
* mmctest
* keyread
* readadc
* usb_read
* usb_write
* fuelgauge
* pmic_read
* pmic_write
To get commands help, Type "help <command>"
SBL> usb
FlashDevRead 63: Error(offset,length,j4fs_end,nErr)=(0x40000,0x1000,0x0,0x80040001)
nps status file does not exist..
nps status is incorrect!! set default status.(completed)
nps status=0x504d4f43

==> Welcome to ARIES!
==> Entering usb download mode..
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!

I was able to reflash everything except a recovery partition on to the phone using Heimdall under Linux. It will not boot... Interesting.... I wonder what the recovery partition does with the boot sequence.
[Hardware Hacking General] midas5:
Looks to me that you will need to flash the pit.
[Hardware Hacking General] AdamOutler:
I flashed back using Odin under a Windows VM. I guess heimdall has a segfault which is to be corrected in the next release.

It looks like eraseall is not as dangerous as we one thought.
[Hardware Hacking General] midas5:
I have not managed to write a pit with heimdall. Something to fix for oneclick. I don't think the recovery partition is important. My phone came from the factory with an empty one.
[Hardware Hacking General] midas5:
Another thing to try is to corrupt the first few bytes of the pbl, so that it is forced into irom recovery.

You can then work on getting the irom recovery working, so that when we finally find the trigger, we will have the recovery steps done.
[Hardware Hacking General] AdamOutler:
Im working on $35 jtag with bus pirate once I finish one-click. Then ill corrupt things... There's more chance of bad stuff with corruption than erase.
[Hardware Hacking General] midas5:
Yes. Once you can repair a brick, you can be more adventurous.
[Hardware Hacking General] AdamOutler:
I just "dd if=boot.bin " onto an MMC... It didn't change anything.. it still found bootable SBL at partition 4.. so much for that one... Do you suppose partition "4" is SBL(0x3) or SBL2(0x4)? I can't partition an sdcard with 0x4 partition without making an extended partition... It would be interesting to find out how the partitioning system really works on the SDCard. I suppose it's probly a function of Samsung's RFS?
[Hardware Hacking General] midas5:
Boot.bin is not what is written to the flash. Better to take a dd copy from bml1 and put that on the mmc .
[Hardware Hacking General] AdamOutler:
I created 4 partitions with pbl pit blank and sbl to match the phones partitions. I also made a card with just a sbl on the device.. no partitions. The partitions were set bootable. The phone did not see them. They were fat16 then I dd'd them and they were unknown and fat16.
[Hardware Hacking General] Jassi_1975:
Hi arround,

I don´t know much about the things you are doing with the hardware specs and hacking etc. but I ´m reading this thread since the beginning and I think about this problem very often.

Can it be that the ubs works in host-mode and a simple usb-stick formated fat16/32 with ONLY all extracted files from a cwm-rom on it are needed?

The same on sd-card may be thinkable.

I ask, because on my old TRINITY P3600 and the ZTE BLADE there ARE some issues, where there only the RIGHT files must be on the RIGHT place...

This is only a question I have after thinking about this and I can´t really help in this things here.
[Hardware Hacking General] AdamOutler:
No. 10char
[Hardware Hacking General] midas5:
Regarding forcing IROM recovery, if the first 4 bytes of onenand are zero, IROM recovery will happen.

There is also a checksum, but i have not yet determined which method it uses, and how many bytes are included.

I guess that if we did ever find the i2c we could use it to force recovery mode.
[Hardware Hacking General] midas5:
Are there any Logic probes that have USB Hi-Speed instead of USB Full-speed.

If so, one could pass data to the PC at about 200Mbps(bits), and then not need any memory on the probe device.

You could then capture a long period to HD, and then analyze afterwards.

I have seen some that work with External PCI-Express, but they are a tad pricey.

External PCI-Express is about 5x USB Hi-speed.

PCIe uses a lot less CPU than USB due to fewer interrupts being needed.
[Hardware Hacking General] AdamOutler:
Yes. They're expensive though. Supposedly the next logic sniffer will support that.

Any good ideas to check?

I could really use a galaxys for disection. I could locate OM resistors by disassembly.
[Hardware Hacking General] midas5:
No new ideas. Not completed the analysis of the onenand loading code yet.

Did you get anywhere with the logic probe? Did you see the ATR message?

Is there anyway to switch between pda and phone mode for the usb link, other than via the app? I.e can the mode be switched on a brick?
[Hardware Hacking General] AdamOutler:
I started a thread in the Captivate section for a main board for dissection. http://xdaforums.com/showthread.php?t=1158431 I suggest someone do this for the i9000 so we can find similarities.

I will pop off the chip, locate xOM5 pin, trace it to the nearest point it can be cut, soldered, jumpered or bridged.
[Hardware Hacking General] AdamOutler:
Anyone want some bootloader code?

http://www.mediafire.com/?l7357ixks1w2x3x

I'd like to thank Azrienoch for this.

It's not a GalaxyS but it uses Loke protocol (odin). It's from a Samsung Acclaim, released July 2010. My bet is that this is likely the same as ours.

uart code anyone?

void InitializeUART(void)
{
/* UART RXD[2], TXD[2] */
*(volatile u32 *)(0x7f008020) = 0x22;

/* UART Setting. */
__REG_UART(UFCON_OFFSET) = 0x0;
__REG_UART(UMCON_OFFSET) = 0x0;
__REG_UART(ULCON_OFFSET) = 0x3;

/*
* EXT_UCLK0 = external clock. (XpwmECLK PAD input)
* EXT_UCLK1 = generated clock by SYSCON.
*
* Here, UART Clock Source = EXT_UCLK1 (= 66.5Mhz)
*/
__REG_UART(UCON_OFFSET) = 0xe45;
__REG_UART(UBRDIV_OFFSET) = 0x23;
__REG_UART(UDIVSLOT_OFFSET) = 0x0080;

/* Clock Setting. */
/* Input clock = 133 MHz assumed. so UART clock = 66.5 MHz (133/22= 66.5). */
*(volatile u32 *)(0x7e00f028) &= ~0x70000;
*(volatile u32 *)(0x7e00f028) |= 0x10000;
#ifdef CONFIG_SEC_LOG_BUF
sec_log_buf_init();
#endif
}

I'm more of a Java guy then a C guy....

We got IBL in assembly... PBL, and SBL in C
[Hardware Hacking General] AdamOutler:
I found this is pbl_ufd.c..

printf("\n");
printf("Primitive Boot Loader(PBL)\n");
printf("Copyright (C) SAMSUNG Corporation 2006-2008\n");
printf("\n");
}[/n]

This is the first thing the PBL does when it launches PBL main.

however if you look at this... in pbl_xsr.c..

{
printf("\n");
printf("!@Start system\n");
printf("Primitive Boot Loader(PBL) built on %s %s\n", __DATE__, __TIME__);
printf("Copyright (C) SAMSUNG Corporation 2006-2009\n");
printf("\n");

It's a bit different... it maybe a different mode. The xsr code is much better documented... However they call the the PBL the NBL2 in this code.... it's odd.

I this is the PBL main routine

void pbl_main(void)
{
InitializeUART();
Board_Init();
print_log();
load_sbl2ram();
while(1);
}

Board_Init() in board.c has quite a bit in it about different boot modes. It seems to be looking at these inputs...

/* BOOT(GPE1) -> Input */
writel((readl(0x7F008080) & ~(0xF << 4)), 0x7F008080);	/* GP#CON */
writel((readl(0x7F008088) & ~(0x3 << 2)), 0x7F008088);	/* GP#PUD */
/* TA_CONNECTED_N(GPL11) -> Input */
writel((readl(0x7F008814) & ~(0xF << 12)), 0x7F008814);	/* GP#CON */
writel((readl(0x7F00881C) & ~(0x3 << 22)), 0x7F00881C);	/* GP#PUD */
/* POWER_N(GPN5) -> Input */
writel((readl(0x7F008830) & ~(0x3 << 10)), 0x7F008830);	/* GP#CON */
writel((readl(0x7F008838) & ~(0x3 << 10)), 0x7F008838);	/* GP#PUD */

/* Reset Time */
writel(0x1, 0x7E005040);	/* RTCCON */
writel(0x0, 0x7E005070);	/* BCDSEC */

Any ideas?
[Hardware Hacking General] ruagun:
hey adam why wont you reply to my pms
[Hardware Hacking General] AdamOutler:
You sent me one PM. Do you think I actually have the desire to respond to every "hey, you seem knowledgeable" PM I get from a guy who just signed up on the site? Not being a **** here... I get a ton of pms from people I dont know about mundane tasks and idle questions better asked on the forums.

If you want an answer; if I were in the market for a phone, I would buy that phone on Ebay.

This is not the place to discuss buying phones or responding to PMs. My PM box is not the place to discuss your purchases either. That is a question for the forums.
[Hardware Hacking General] midas5:
Deleted

deleted
[Hardware Hacking General] AdamOutler:
you got to drill down

adam@Adam-Desktop:~/Desktop/bootloader$ ls
build_kernel.sh libWebCoreSQLite3.a pvplayer.cfg src
iperf-2.0.4 pppd README.txt
adam@Adam-Desktop:~/Desktop/bootloader$ cd src
adam@Adam-Desktop:~/Desktop/bootloader/src$ ls
kernel modules packages
adam@Adam-Desktop:~/Desktop/bootloader/src$ cd kernel
adam@Adam-Desktop:~/Desktop/bootloader/src/kernel$ cd bootloader
adam@Adam-Desktop:~/Desktop/bootloader/src/kernel/bootloader$ ls
loke
adam@Adam-Desktop:~/Desktop/bootloader/src/kernel/bootloader$ cd loke
adam@Adam-Desktop:~/Desktop/bootloader/src/kernel/bootloader/loke$ ls
bin common config.sh Kconfig make.sh Sbl
cc.mk configs Ibl Makefile Pbl scripts
adam@Adam-Desktop:~/Desktop/bootloader/src/kernel/bootloader/loke$ cd pbl
bash: cd: pbl: No such file or directory
adam@Adam-Desktop:~/Desktop/bootloader/src/kernel/bootloader/loke$ cd Pbl
adam@Adam-Desktop:~/Desktop/bootloader/src/kernel/bootloader/loke/Pbl$ ls
arch include license.txt Makefile
adam@Adam-Desktop:~/Desktop/bootloader/src/kernel/bootloader/loke/Pbl$ cd arch/arm/mach-s3c/main
adam@Adam-Desktop:~/Desktop/bootloader/src/kernel/bootloader/loke/Pbl/arch/arm/mach-s3c/main$ ls
board.c Makefile memutil.c pbl_ufd.c printf.c

All the interesting stuff is in the /src/kernel/bootloader/loke folder
[Hardware Hacking General] lownoise:
Adam,

I know you're looking for "interesting" functions in the PBL;)

But when looking through de source code i found some nice functions in the SBL tree

If you look at the file /src/kernel/bootloader/loke/Sbl/drivers/s3c/s3c_mmc.c we see functions related to download from sdcard.

Comparing some strings extracted from our sbl.bin reveals that may bee these functions are implemented as well...

Looking through the code and functions it looks like it's possible to flash the phone if we place the files in a directory with the correct names......