How to dump the bootloader from UA65ES8000

[dajojo]

brick bug is OS safety procedure going in loop so keep on secure erase parts of the eMMC chip while OS driver try to repare it thus destoying it (firmware chip writes blocks while OS writes the drivestructure ( > secure erase - drive write - secure erase - drive written is checked - wrong - written again - secure erase check fail - secure erase again.its coz no fault-handler) it is android based and not chip-specific thus not affecting our tv. the watchdog rebooting the tv is the thing u speak about which is the mechanism that does this procedure , in phone its bootloader. however you can destroy tv by not respecting micom locations which are some hardcoded. i.e. dont write code to chip if u dont know what ur doing. dont mess up bootloader of phone with the one of tv its not the same. the mem chips in ssd drives also have different firmware on it to directly speak to it where tv has firmware on it with specific pointers and security keys and stuff.
patching would be option on phone since it same hardware,OS,kernel this can be accomplished with checks and you can run memreader to find code in mem.this tool u advertised over in XDA.

[E3V3A]

@dajojo: Sorry, but I find you post completely irrelevant, or perhaps I just don't understand you. What's your point (if any)? (And how does it help this thread?)

[xorloser]

I am just running a stock system atm too, when I get some more time I will actually use the info I worked out to create something In the meantime I just run scripts via the copyfile exploit using some javascript widget that I wrote to do so safely (ie it removes the /etc/profile dangers). The upside is that it should work to run scripts on any system. Btw dumping mem at address 0x100 is no help, I need a dump of kernel code to see what address it is running at.

I built and ran viewmem and it worked fine here. I wrote my own version, called readmem, that supports writing to a given filename too, just in case that is your issue. I have attached both to this post. For the record the dumps that I tried were:

Code: Select all

shell>/tmp/readmem 0x40000000 0x1000 dump_rm.bin
Dumping memory from 40000000 - 40001000 to dump_rm.bin
Dumped memory successfully
shell>/tmp/viewmem 0x40000000 0x1000 > dump_vm.bin

[dajojo]

ok just checking, u dont wanna mess up ur tv by probing wrong areas
i wont bother to explain that cygwin is not working to compile offcourse since u know what ur doing.
it would be helpfull to give us the real kernel data so we can look for a decent patching solution.

@xor u recon overflow on the copyfile would give us bypass to eMMC write-routine ?

[xorloser]

exploiting the javascript call to copyfile lets you run commands as root, at which stage you can do whatever you want I guess. the exploit was found by thwalker3 iirc, I just wrapped it in some easy to use javascript code and use some protection against formatting/micom rollback that can occur due to contents of /etc/profile

[dajojo]

exploiting the javascript call to copyfile lets you run commands as root, at which stage you can do whatever you want I guess. the exploit was found by thwalker3 iirc, I just wrapped it in some easy to use javascript code and use some protection against formatting/micom rollback that can occur due to contents of /etc/profile

thnx
so we still have this problem with : ; characters ?
perhaps someone can take a look at smarthub remote setting in new firmware. when u turn this on and turn off the tv and pull plug off wall, then put plug back and turn on with bluetooth on smartview 3.20 (used s3) the tv has remote port open but some things missing and tv doesnt accept remote input like channel up but want to accept something on http ports (it does react on IR remote). normally it wont have this acces.
perhaps its the social media app taking over control since it got a little messed up by adding old google talk client to it. seems it got jammed like when in overflow. as soon as i hit the button on IR remote for page-up the tv clicks and start image and logging in to smarthub and such. there is a possible breach here since phone allready connected to tv.

[E3V3A]

... I wasn't actually that interested in the data itself, but more in the calling of the kernel ioctl to dump the smart data....

I'm trying to understand the ioctl's (?) that you use in your mmcsmart.cpp. For example: "GET_SMART_REPORT 0x5627" what does this code mean, and where is it used? It doesn't seem part of the standard JEDEC CMD's, so I'm trying to find/understand if it refers to a memory location (of the eMMC bootsector) or something else. Basically I'm trying to cross compile your tool to be used for other devices, but the "codes" above are nowhere to be found. So they must represent something else...

[xorloser]

The ioctls are just "magic numbers" that the kernel recognises and knows how to respond to. So unless the ioctl number in question is part of some standard, it is indeed just a "magic number". So unless your kernel was built with the ability to understand and know how to respond to ioctl number 0x5627 (for get smart info) the number is meaningless. I would assume that samsung would reuse that ioctl number for a lot of their TVs, merely because they would be reusing the underlying emmc sourcecode. Whether it is used in other product lines however I cannot say, you would need to either try it or reverse the kernel from other products to see.

In my patches to read out the bootloader, I just made up magic numbers for the read ioctls by incrementing the write ioctl numbers by 0x10. I could have just reused the write ioctl number, since I patched the write routines to do reads anyway. However in the event that my patches were not applied correctly I didn't want it to go ahead and try to write! So by using different ioctl numbers, if my patches had failed for some reason it would treat the ioctl as unknown and not handle it. A much better scenario than blindy overwriting my bootloader with garbage

E3V3A: I take it that the viewmem and readmem I compiled didn't work for you either then?

[dajojo]

so u can write the whole eMMC area with the write routine i.e. reverse the writing-routine for bootloader ? nice fail-routine btw

[E3V3A]

E3V3A: I take it that the viewmem and readmem I compiled didn't work for you either then?

Nope. I get: "Error mem-mapping /dev/mem"

It seem that problems could be:
1. There's some shit protecting that memory area.
2. The mem location you gave me, doesn't exist.