yashsingh1/xdaforums huggingface dataset:
[Samsung Epic 4G Touch] Epix4G:
So is eg12 the modem and eg30 was eg12 with a delta patch applied...and when its pulled its just not pulling the delta patch
[Samsung Epic 4G Touch] Dchibro:
Plausible theory I'd say. Well, it passes my common sense test anyways, given I know nothing about the technical programming details.
[Samsung Epic 4G Touch] sling:
Thats what I'm thinking
[Samsung Epic 4G Touch] Duce HD2:
Calk, I found this in one of the SGS2 threads....probably already tried though?...

I don't have the EG30 modem anymore so can't give it a shot, what do you think?

http://xdaforums.com/archive/index.php/t-1198827.html
[Samsung Epic 4G Touch] ervman1:
yeah I wasn't sure but I saw posted in qbkings stickied post where he said eg12 is exact same as eg30
[Samsung Epic 4G Touch] d1msum4lyfe:
someone with a eg30 give it a shot?
[Samsung Epic 4G Touch] Dchibro:
Actually, I think the confusion springs from how a pull from a EG30 phone resulted in a EG12 modem file, and a file comparison Calk did.

Awhile back, Calkulin did a file comparison between files listed as EG30 and EG12, and found them to be identical.

Here was his post ...

http://xdaforums.com/showpost.php?p=18715115&postcount=12

But I think this was a side affect of comparing two identical files that were simply named differently. The issue, which prompted this thread in the first place, is the fact that no matter what we do, pulling the modem off our phones will currently result in a EG12 baseband, no matter what the file is called.
[Samsung Epic 4G Touch] Calkulin:
That's not the reason we are pulling EG12 from that location, Chris is right is saying that partition was filled with EG12 from the factory but it's not actually used, so the (used) modem is actually somewhere else and since we don't know the location, we can't pull it
[Samsung Epic 4G Touch] sling:
He is wrong.

Like Epix4G I'm thinking its patch applied to EG12 base.

If that's the case were would patch be thrown & extracted
[Samsung Epic 4G Touch] Dchibro:
I'm fairly sure this is how they've been pulling the file already, however, it's not resulting in the EG30 modem.
[Samsung Epic 4G Touch] sling:
hmm If there was only a way to follow path of modem during full 31 tar flash through odin
[Samsung Epic 4G Touch] nivron:
I'm not 100% sure, but isn't it possible to write an app that would read the modem.bin via the dpram driver in the kernel? That's apparently how the firmware is uploaded to the device, in recovery (drivers/dpram/dpram_recovery.c IIRC).

I don't have the Samsung kernel source in front of me, but if there is a method to write the code, maybe we can write a method to read it as well.

I'm a little rusty at the moment, but I'm sure one of the talented devs here could probably whip something up. Otherwise I may try this angle when I get some free time.
[Samsung Epic 4G Touch] crawrj:
What location does the pit show for the modem?
[Samsung Epic 4G Touch] cordell12:
I contacted Sammy @ opensource, worth a shot...
[Samsung Epic 4G Touch] chris41g:
https://github.com/chris41g/LoStKernel/blob/master/Kernel/drivers/dpram/raffaello/dpram_recovery.h

https://github.com/chris41g/LoStKernel/blob/master/Kernel/drivers/dpram/raffaello/dpram_recovery.c

---------- Post added at 05:18 PM ---------- Previous post was at 05:16 PM ----------

dpram_recovery_WriteImage(u8 *const pBuf, u32 dwWriteLen)
{
u8 *pDest;
u8 *pDest_Data;
u16 Len;
u16 nCrc;

/*printk(KERN_DEBUG "Start %d 0x%04x(%d)\n", dwWriteLen, g_TotFrame, g_TotFrame);*/

pDest = (u8 *)(dpram->dpram_vbase + DPRAM_PDA2PHONE_FORMATTED_START_ADDRESS);
Len = (u16)min(dwWriteLen, FODN_DEFAULT_WRITE_LEN);

/*printk(KERN_DEBUG "Start : pDest(0x%08x), dwWriteLen(%d)\n",pDest, Len);*/

/* Start Index */
*pDest++ = LOBYTE(START_INDEX);
*pDest++ = HIBYTE(START_INDEX);

/*Total Frame number: */
*pDest++ = LOBYTE(g_TotFrame);
*pDest++ = HIBYTE(g_TotFrame);

/*Current Frame number; */
*pDest++ = LOBYTE(g_CurFrame);
*pDest++ = HIBYTE(g_CurFrame);
g_CurFrame++;

/* Length - Does it include the length of START_INDEX?? */
*pDest++ = LOBYTE(Len);
*pDest++ = HIBYTE(Len);

/* Data */
pDest_Data = pDest;
memcpy((void *)pDest, (void *)pBuf, Len);
pDest += Len;

/* Fill null if data length is odd */
if (Len%2 != 0) {
*pDest++ = 0xff;
printk(KERN_DEBUG "odd 0x%08x 0x%02x\n", (unsigned int)(pDest-1), (u8)(*pDest-1));
}

/*printk(KERN_DEBUG "len:%d default len:%d\n", Len, FODN_DEFAULT_WRITE_LEN);*/
/*printk(KERN_DEBUG "start data 0x%08x \n", pDest);*/

if (Len < FODN_DEFAULT_WRITE_LEN) {
memset((void *)pDest, 0x0 /*0xff*/, FODN_DEFAULT_WRITE_LEN - Len);
pDest += (FODN_DEFAULT_WRITE_LEN - Len) ;
}
printk(KERN_DEBUG "CRC start 0x%08x\n", (unsigned int)pDest);

nCrc = dpram_recovery_MakeCRC(Len, (u16 *)pDest_Data);

*pDest++ = LOBYTE(nCrc);
*pDest++ = HIBYTE(nCrc);

printk(KERN_DEBUG "CRC value 0x%04x \n", nCrc);

*pDest++ = LOBYTE(END_INDEX);
*pDest++ = HIBYTE(END_INDEX);

/* Write Command*/
dpram_recovery_WriteCommand(CMD_FOTA_IMG_SEND_REQ);

return Len;
}
[Samsung Epic 4G Touch] numus:
Edit: Removed post
[Samsung Epic 4G Touch] joeykrim:
As far as I've seen in both CM and AOSP, the update-binary is a fairly generic binary built at compiliation time. I think there are roughly 3 API levels corresponding to the amount of command args provided to update-binary. This should all be documented in AOSP along with the source code.

Not sure why you'd want to decompile something which is already open source? More detail around this request might help us understand better what the goal is with the update-binary file?

Very clever logic and I think this definitely could be possible. Would want to look through the source code to see how this all setup and handled.

Lol. Perfect post with source code! Gotta love Samsung's source code. They left all their debugging code in tact and only commented it out. Should make it a bit easier to experiment with.

First, I'd look through the source code to find where the method quoted above is called from: "dpram_recovery_WriteImage". We want to see the values passed into this and understand how/when/where it is called.

Also, if anybody feels daring enough. We can comment out the actual commands that do the writing, and only leave the debug commands turned on, compile and run a test update so we can see the debug output which would provide us the parameters for the command, plus some more insight into the command itself actually working.

After all of this, I think it *should* be possible, at least in theory to reverse the method to open at the same location and read out the data stored instead of the current method writing to the location.

All of these are some thoughts off the top of my head after reading through the thread commentary. Keep the ideas coming as brainstorming is very helpful. I think the current approach definitely could work but will take a lil bit of effort coding/testing.

Great to see everybody working together!
[Samsung Epic 4G Touch] pyrostic:
Joeykrim I think you are onto something with that noggin of yours.
[Samsung Epic 4G Touch] Shoulon:
Bringing back the ida program. Couldn't we use hex keys to locate duplicates of the modem? Use the eg30 modem from tar. Use Ida to find the same values in a decompiled tar
[Samsung Epic 4G Touch] autoprime:
might also be a good idea to poke around AFTER unlocking the EFS/NVM.

##8778# > CP > add com port via qpst configuration app

after com port is added to qpst open cdma ws > security tab > send password

samsung password = 01F2030F5F678FF9

after password has been sent successfully.. continue poking around partitions etc.. might unlock something that wasn't showing up before.
[Samsung Epic 4G Touch] jerdog:
Did that earlier today - he doesn't know but gave me a few other contacts
[Samsung Epic 4G Touch] Sterist:
wireshark odin and log the location that it flashes the modems to?
[Samsung Epic 4G Touch] d1msum4lyfe:
good idea :D
[Samsung Epic 4G Touch] adma84:
does the modem get loaded over a serial connection? If so, could you replace the TTY KO with a patched one that allows you to watch the entire transaction? This would be similar to how Charlie Miller fuzzed the baseband on iPhone a few years ago
[Samsung Epic 4G Touch] d1msum4lyfe:
Im just going to assume that it does because of using com port when connected with odin
[Samsung Epic 4G Touch] chris41g:
in odin it would be serial, but i believe(baseless assumption) that odin mode devices will be different than recovery mappings
[Samsung Epic 4G Touch] kawasaki00:
Boy this thread is pretty far over my head, I enjoy reading through it all and seeing all you guys working together on it though.
[Samsung Epic 4G Touch] Sycobob:
I've no experience with this type of development, but I'll throw in a couple of ideas, just in case it helps.

Looking at the dpram_recovery_WriteImage() method chris41g posted, it looks like that copies the file to RAM, pads it with empty data, and creates a CRC check, then calls dpram_recovery_WriteCommand() to actually copy the data to the partition on which it belongs (presumably using the CRC to check that the write was successful). My guess is the second method may be more illuminating, as it's the one that actually knows where the modem goes. Either the argument is a constant set somewhere else containing the path, or the path is in the function itself.

You might be able to use Odin itself to see where the modem goes. I don't know anything about the inner workings of Odin, but if the program itself contains the information about where to send the modem, could you analyze what it's sending/doing? If one Odin works for all phones, it's doubtful this would work. Odin probably just sends a modem and the phone handles where it goes.

If EG30 really is a delta applied to EG12, could you apply EK02 to EG30 and see where the delta is stored? If the delta is stored seperately from the original modem file, it's possible the known partition with EG12 is the correct one, and the delta is stored and used somewhere else.

Doesn't the pit file contain the partition information? Doesn't that give all the possible locations the modem can be?

Just for ****s and giggles:

If you remove the EG12 modem from the unused partition, will the phone repopulate it? If so, it can only use the modem that's still on the phone. Doubtful, but who knows.

Like I said, I've never dealt with OSs and this type of stuff (wish I had the time, to be honest) so these are just guesses.
[Samsung Epic 4G Touch] Sterist:
in regards to if the phone were to handle where the modem goes... could dump the bootloader and emulate? bit much effort though lol

i think that might actually be the case because odin is not phone-specific. it would need a database with instructions for each phone, or odin receives instructions via com
[Samsung Epic 4G Touch] chris41g:
I like that idea, and your post all around..
[Samsung Epic 4G Touch] Calkulin:
Nice to see you around these part Joey ;) The reason for the update-binary is just curiousity on my part, I just want to see all the commands that are available for it. Hex editor shows me some but it's a pain trying to read all of them.

As for your kernel theory, I don't have an environment to build kernels but if someone want to try, I will be happy to help with anything I can
[Samsung Epic 4G Touch] Calkulin:
I actually have that partition formatted and it did nothing, so that partition is not used for anything
[Samsung Epic 4G Touch] joeykrim:
The guesses you've made are very very good. I would take your guess any day!

Regarding the dpram_recovery_WriteImage() and WriteCommand() methods, I agree 100%. I am thinking the path might be passed along or inside the function. If somebody could post up the source for the WriteCommand function, would be very interesting.

Off the top of my head, if we can write the data, we should be able to read the data. Reversing the write function into a read function should be able to provide us the actual modem ...

The only other thought which comes to mind, is perhaps the write function puts the modem in a temporary location which the device then reads and internally moves to the final location ...

Looking at the next method, WriteCommand() should provide more insight!

Always looking to help out! Regarding the update-binary, there are two main ideas which come to mind.

1) Samsung very well could have made their own update-binary, in which case we'd have to reverse it to understand it.

2) If Samsung used AOSP to build their update-binary, the source code would be available for all. I went and found the exact file which shows all the commands handled by update-binary. The comments in the file give example usage and syntax in case C++ isn't a strong suite. Link: https://github.com/android/platform_recovery/blob/master/commands.c

Great ideas and some great contributions. Lets keep the ball rolling! Hope my feedback is helpful!
[Samsung Epic 4G Touch] Euclid's Brother:
I've been looking at that recovery code from Chris' LoStKernel (https://github.com/chris41g/LoStKernel/blob/master/Kernel/drivers/dpram/raffaello/dpram_recovery.c).

It appears that the code set's up the image in a spot in RAM that the modem can access, then sends a command to the modem to have it flash itself. The dpram_recovery_WriteImage function set's up data to be flashed, then dpram_recovery_WriteCommand tell's the modem to "flash"

Here's the commands that can be sent

#define CMD_FOTA_IMG_RECEIVE_READY_REQ	0x9100
#define CMD_FOTA_IMG_SEND_REQ	0x9200
#define CMD_FOTA_SEND_DONE_REQ	0x9300
#define CMD_FOTA_UPDATE_START_REQ	0x9400
#define CMD_FOTA_UPDATE_STATUS_IND	0x9500
#define CMD_FOTA_INIT_START_REQ	0x9A00
#define CMD_FOTA_INIT_START_RES	0x9B00
#define CMD_FOTA_UPDATE_END_IND	0x9C00

None of these tell the modem to dump itself to memory that we can access..

However, there seem to be lots of interesting functions in this file.

https://github.com/chris41g/LoStKernel/blob/master/Kernel/drivers/dpram/raffaello/dpram.c

like:

static void _Request_ModemData(u32 addr, u32 size)

static void start_cp_ramdump(void)

static void receive_cp_ramdump(void)

Chris, do you know anything about these functions and what their used for? Or would we still be stuck with not being able to get the firmware pulled into dpram in order to dump it?
[Samsung Epic 4G Touch] sfhub:
That does sound promising.

The labeled gpio function look like they control a software programmable gpio (general purpose i/o) interface and it can be programmed to work in either direction.

Probably someone can start with uploading the EG31 modem.bin where we have a known dump and then start playing with the dpram functions to see if we can get data from the phone back into RAM rather than from RAM into the phone. Then dump the memory and compare to the EG31 modem.bin until we can get an exact match.
[Samsung Epic 4G Touch] joeykrim:
I might have missed something and its been a long day but I'm wondering and trying to bridge a gap.

I probably missed this somewhere, but where/how are these commands currently called? Was update-binary method because we thought they were being called through there somehow?

Do we have a copy of an OTA file they've given out that makes the call through the recovery via updater-script?

In order to close the logic loop, these methods seem very helpful and now I'm wondering how we access these methods which are setup in the kernel ... Being able to access these methods will make the next step of testing fall into place a bit easier, I hope!

The methods mentioned above, such as receive_cp_ramdump:

https://github.com/chris41g/LoStKernel/blob/master/Kernel/drivers/dpram/raffaello/dpram.c#L495

seem to be setup to receive data coming from the modem.

This is definitely great work. The more people look over these files the more helpful information we pull out!
[Samsung Epic 4G Touch] JohnCorleone:
I just wanted to thank all of the great minds trying to tackle this issue.
[Samsung Epic 4G Touch] trim81:
I'm not in any way a developer, but I just had a thought.

Can someone first send the samsung default password (used to gain access to the modem) via cdma workshop or qxdm, then run the getram/modem command?
[Samsung Epic 4G Touch] spdwiz18:
Just want to say thanks. And if you need a sacrificial lamb for testing. I'm willing.
[Samsung Epic 4G Touch] AestenD:
Last night kings mentioned a method the devs wanted to test, as long as the guinea pig was in the southeast.... that offer still on the table?
[Samsung Epic 4G Touch] lballer69:
He found someone he's waiting until Monday to try .
[Samsung Epic 4G Touch] autoprime:
i mentioned sending the default password on page 3.. but was unaware of a qxdm modem command?

which commands are these?
[Samsung Epic 4G Touch] trim81:
Password (samsung default)

Then enter
[Samsung Epic 4G Touch] autoprime:
nah i knew that.. i thought you were saying there was a qxdm "get modem" command or something. so youre just suggesting unlocking the efs with the default password and then trying to do what theyre doing? thats pretty much what i suggested on page 3 at the bottom and also agree. UNLOCK THE EFS WITH QXDM FIRST AND THEN PROCEED :D
[Samsung Epic 4G Touch] numus:
Has anyone taken the time to actually count bytes and make sure all are accounted for? We should know the exact storage size of the chips used.
[Samsung Epic 4G Touch] Calkulin:
Hex editing the modem to say EG30 didn't work but I don't know if the delta update is looking at the timestamp also, which I don't have for EG30.

Just for giggles, I edited to have today's date, so before ANYONE post, this is a hex of EG31,

THIS IS NOT REAL
[Samsung Epic 4G Touch] xlGmanlx:
Somewhere this will get lost, nice idea a la xoom update
[Samsung Epic 4G Touch] chris41g:
a delta doesnt check any string, or timestamp... it checks the sha.. it actually only contains the differences between eg30 and ek02... so even if you could get the same sha, the internal differences would cause the patch to fail.
[Samsung Epic 4G Touch] sfhub:
Hi Chris,

Where is the SHA checksum being checked for the modem delta? I see all the other files being checked in the script, but not modem_delta.bin.

Is it being checked implicitly in the write_firmware_image command?

If we can see where the SHA checksum is being checked, doesn't that imply the installed modem.bin can be read and shouldn't we then be able to read the rest of the installed modem.bin by using whatever routines are being used to check the SHA checksum?
[Samsung Epic 4G Touch] Shoulon:
Lies he's holding out on us! Get him!

</end spam>
[Samsung Epic 4G Touch] Calkulin:
If it's doing a sha check, then why is it accepting the flashes to sections 4, 13 & 20?
[Samsung Epic 4G Touch] kingsway8605:
This isn't even close to what I said lol.
[Samsung Epic 4G Touch] chris41g:
more digging in recovery code lastnight, shows what MAY be happening.. looks like it copies the modem delta to /cache then sets a bootloader message, and the bootloader actually applies the update..
[Samsung Epic 4G Touch] kingsway8605:
I pulled the ota update.zip from /cache, so that part is definitely true. Can't speak to the bootloader applying the update, but definitely would make sense.

Don't know if it is any help, but when you try to apply the automatic ota, a yellow exclamation point appears about 2/3rds the way through with no error message, the phone reboots, and the pre-update backup re-installs itself after reboot.
[Samsung Epic 4G Touch] JahmeZZ:
Thank You for all the hard work
[Samsung Epic 4G Touch] leodesol:
I am a noob when it comes to android programming and phone hardware, but the problems I have had with my phone caused me to become pretty interested in watching the community development progress. I decided to do some research on my own and found some things that may be helpful. Forgive me if this is common knowledge already....

I found specs for the phone online and they indicate that the Cellular Phone functions uses the Qualcomm QSC6085 Chipset. Qualcomm calls this a "Single Chip Solution" because it bundles several component functions into one chip; baseband modem, RF transceiver, power management, and multimedia processor.

Finding this info, I also found that several other Andriod devices use this chip, and several of those devices seemed to present similar challenges to the dev community. A few I know of are: Droid X, the Sprint Galaxy Tab, and the Sprint Epic 4G. Perhaps some of the solutions devs discovered on those models will be of some help here?

Last, but not least. I found these PDFs with a ton of the technical details on the chipset:

http://www.droid-developers.org/images/2/25/Qsc6085-audio.pdf

http://read.pudn.com/downloads161/s...RAINING__INTRODUCTION_AND_DEVICE_OVERVIEW.pdf

For example, the first one gives you data like this (and much more):

By leodesol at 2011-12-07

Hope this helps.
[Samsung Epic 4G Touch] Euclid's Brother:
Very interesting indeed. Specifically the part about JTAG connection to the chip (boy does that bring back some memories). That should be one way of dumping pretty much anything from it, although it's pretty invasive. It might be difficult to connect to the jtag pins with the chip onboard. Unless they were kind enough to put connect pads elsewhere on the board. Does anyone have teardown pics of this phone?

While reading that stuff about jtag, i'm wonding if ODIN mode is just a pass-through to jtag? Is there source code available for odin?
[Samsung Epic 4G Touch] MadFlava:
Here's a teardown

http://www.ifixit.com/Teardown/Samsung-Epic-4G-Touch-Teardown/6481/1
[Samsung Epic 4G Touch] Euclid's Brother:
Alas, I see no convient jtag pads on the board, which would mean removing the chip to jtag :( unless odin somehow usings the jtag interface. It's a long shot I guess. Need to see odin source code to know.
[Samsung Epic 4G Touch] enormous:
Heimdall's source help?

https://github.com/Benjamin-Dobell/Heimdall/tree/v1.3.1
[Samsung Epic 4G Touch] autoprime:
we have someone on IRC that has a jtag box and has worked with this phone. hopefully hes online in the next few days and we can see if he can dump those ranges.
[Samsung Epic 4G Touch] Wizard Knight:
just a question... now that the update is rolling out officially. can't the modem tar (or whatever) just be pulled from an not-yet-installed update download?

just curious. I'm one of those who is on EG31 (which I actually found to be a noticeable improvement over EG30)
[Samsung Epic 4G Touch] cidica:
that's saying it's a full modem install and not just the delta that was sent to king. My guess is this being an update it's going to be the exact same thing that we have here now where the modem is just the delta update file and not a full modem install.
[Samsung Epic 4G Touch] chris41g:
ota updates from sprint on samsung devices always are just a delta.. have to have a tar for full modem.bin
[Samsung Epic 4G Touch] datajosh:
Hopefully they just send out a full EK02 TAR to the repair centers soon now that it's official.
[Samsung Epic 4G Touch] Sterist:
like enormous said, try heimdall source?

.... or wireshark odin?
[Samsung Epic 4G Touch] Will of fire:
I saw that too
[Samsung Epic 4G Touch] slixzen:
Have we tried this yet?

Taking the .tar of the EG31, removing the delta file, and replacing it with the EG30 version? Or somehow tweaking the tar file to accept the EG30 modem & kernel?

For instance, is there any way to just disable it force checking the signature? Or could we just try to find some way to recreate it with the exact same Sha hash?
[Samsung Epic 4G Touch] random45:
We dont know if we even have the EG30 modem. we just have the useless EG12 (i dont know a whole lot, just giving what little i know)
[Samsung Epic 4G Touch] Wizard Knight:
I haven't had this phone for too log but couldn't we just Odin to stock ed12 (or whatever it is), ota updates to EG30, then ota to EK02?
[Samsung Epic 4G Touch] sling:
There is no OTA 30 available
[Samsung Epic 4G Touch] Wizard Knight:
then how did people go from 12 to 30?
[Samsung Epic 4G Touch] slixzen:
There isn't an OTA update for EG30.

I was ninja posted.

But to answer your question, they didn't. And if they did, please link me, because it would be nice to be back on EG30.