Admin copies this topic from old forum;
Elliot said that:
----------------------------------------------
Hi,
with regards to the LNxxB650 and B679 with CI+ certification I have been trying to figure out a way in as well for some days now.
Unfortunetly I have not been successful, yet.
Anyhow maybe it maybe interesting for others to know as well that there at least seems a way to execute "home brew" swf-flash files.
Actually this works via the possibility to run Content-Libary programs from a USB-Stick.
Download an application from:
www. samsung. com /at/consumer/learningresources/medi2.0/library_download.html
I had downloaded a Children learning program
After extracting there will be a clmeta.dat file which is pure text XML.
It will point for your language set (in my case german) to the file that is executed when playing the content. In my case this has been storybook.swf in the deu sub directory.
I had placed the extracted content in a "Children" subdirectory on a USB-Stick. You may want to play the original content first before doing any modification.
If you saw it working you may just replace the swf file by your own. I did not notice any security mesures while a package size had been shown in the xml file which seems to be ignored.
Then I downloaded mtasc from (mtasc.org - the haxe.org compiler should also work while I did not try it out) freeware compiler, used their "hello world" example, compiled it and exchanged the storybook.swf with my own hello_world-version.
When played on the TV-Set a white screen appeared with the Hello-World message shown.
I have tried out several things to start the telnetd without success so far.
- I tried to use the fscommand Action-Script-Command to execute telnetd from /bin or from a local subdirectory fscommand within the deu subdirectory.
- I have tried out so far only one other swf game from www . purple-twinkie . com /games/swf/frogmania.swf. This seldomly started up but more often crashed the TV while sometimes showing even a shell # on the debug serial service console, but no input could be made via a terminal program on my CI+ TV, unfortunetly.
- I tried to put the files on a EXT3 formatted USB stick in order to possibly have execution rights on the file-system, but here it seemed like the stick would be mounted by the linux system but not accepted by the TV application (checked with 1005.1 and 1006.0 FW version of the B679 model).
Hope you have fun with this.
Best Regards,
Elliot!
LNxxB650 and B679 with CI+ certification
-
- Official SamyGO Developer
- Posts: 1700
- Joined: Fri Oct 02, 2009 8:52 am
- Location: Austria/Vienna (no Kangaroos here)
- Contact:
Re: LNxxB650 and B679 with CI+ certification
yes, i think it is a smarter way to "extend" the tv functions over the media content as hexedit the firmware.
if you look at the games content you can see it is possible to set the startfile to a shared object, may
also to a html page/adress.
we have to made some tests about the webbrowser and javascript capabilities of the device.
may it is also possible to extend the mainmenu.swf & submenu.swf
arris
if you look at the games content you can see it is possible to set the startfile to a shared object, may
also to a html page/adress.
we have to made some tests about the webbrowser and javascript capabilities of the device.
may it is also possible to extend the mainmenu.swf & submenu.swf
arris
- erdem_ua
- SamyGO Admin
- Posts: 3126
- Joined: Thu Oct 01, 2009 6:02 am
- Location: Istanbul, Turkey
- Contact:
Re: LNxxB650 and B679 with CI+ certification
I inspected T-CHLCIPDEUC firmware and I saw an encryption key at the end of the file.
public key signature in ASCII 256 bytes

So who decypher it?
New GPU's has lots of power for crack this key.
I could also make some OpenCL stuff to bruteforce it with next generation GPUs.
Again it's futile to trying to crack SSL 256 with a single GPU. Oppps, it's 128 bit!
Yes. Because of ASCII. Himm than brute forcing became logical to me
It's just fun since we can download firmware with Telnet.
But making a program to crack SSL on GPU, priceless
public key signature in ASCII 256 bytes

So who decypher it?
New GPU's has lots of power for crack this key.

I could also make some OpenCL stuff to bruteforce it with next generation GPUs.
Again it's futile to trying to crack SSL 256 with a single GPU. Oppps, it's 128 bit!
Yes. Because of ASCII. Himm than brute forcing became logical to me

It's just fun since we can download firmware with Telnet.
But making a program to crack SSL on GPU, priceless

-
- SamyGO Admin
- Posts: 62
- Joined: Sun Oct 04, 2009 12:35 am
Re: LNxxB650 and B679 with CI+ certification
[quote=erdem_ua]It's just fun since we can download firmware with Telnet.[/quote]
We have not yet managed to get telnet access on CI+ devices, why getting the CI+ images decrypted is still a challenge to be mastered, which no one of us had the knowledge to start with.
It sounds that you have some experience with this and a couple good ideas to start off with - this is great and what we missed.
As such I would say: Go erdem go
!!!
Another alternative will be to alter the bootloader ( it seems to be uboot ) to boot e.g. the image of a CI device, which would allow to read out ( bml.dump ) and alter the image directly from the flash contents.
This however is worth a separate thread, which I'll take care of
Regards
dynamic
We have not yet managed to get telnet access on CI+ devices, why getting the CI+ images decrypted is still a challenge to be mastered, which no one of us had the knowledge to start with.
It sounds that you have some experience with this and a couple good ideas to start off with - this is great and what we missed.
As such I would say: Go erdem go

Another alternative will be to alter the bootloader ( it seems to be uboot ) to boot e.g. the image of a CI device, which would allow to read out ( bml.dump ) and alter the image directly from the flash contents.
This however is worth a separate thread, which I'll take care of

Regards
dynamic
Re: LNxxB650 and B679 with CI+ certification
I had a quick look at the disassembly generated with armv5 objdump inserted in a perl script designed for x86 code disassembly and processing.
(Got that from a reverse engineering site ages ago)
The script output is legible, but I need to tweak the perl script to handle arm assembly code. That will take some time, because I'm not really fluent in perl, and the upcoming week promises to be very busy.
I'll keep you posted.
(Got that from a reverse engineering site ages ago)
The script output is legible, but I need to tweak the perl script to handle arm assembly code. That will take some time, because I'm not really fluent in perl, and the upcoming week promises to be very busy.
I'll keep you posted.
- erdem_ua
- SamyGO Admin
- Posts: 3126
- Joined: Thu Oct 01, 2009 6:02 am
- Location: Istanbul, Turkey
- Contact:
Re: LNxxB650 and B679 with CI+ certification
Might be a useful information. 
b457144n told that at old forum:

b457144n told that at old forum:
A quick diff against the 'regular' B650 linux sources shows lots of interesting stuff. Apparently the T2P kernel runs a progam '/bin/authuld' that verifies whether files have been modified and will request a reboot if modifications have been detected.
judging by the string present in exeDSP I suspect the key is in the rw area of the firmware. Also the boot log says 'SWU Production Key'. Thirdly I think the purpose of the whole encryption stuff is to satisfy the auditors for the HDCP license that the HDCP key won't be compromised. They won't accept a simple project name as a key (or the XOR encryption).
As mentioned earlier in this thread the *.sec files probably have been encrypted with OpenSSL (which unfortunately has been linked statically with exeDSP). The XOR images are a multiple of 4KB in length. That makes my guess for the layout of the sec files as follows:
'Salted__' 8 bytes
the salt 8 bytes
encrypted image X 4KB
MD5 checksum 16 bytes
unknown 1 byte
public key signature in ASCII 256 bytes
'256' (signature length?) 3 bytes
This fits the lengths of all the .sec files I've checked so far.
- erdem_ua
- SamyGO Admin
- Posts: 3126
- Joined: Thu Oct 01, 2009 6:02 am
- Location: Istanbul, Turkey
- Contact:
Re: LNxxB650 and B679 with CI+ certification
Key of d3e90afc-0f09-4054-9bac-350cc8dfc901-7cee72ea-15ae-45ce-b0f5-611c4f8d4a71 looks 2x128 bit key to my eye because of they have same pattern of dashing.
Key1: d3e90afc-0f09-4054-9bac-350cc8dfc901
Key2: 7cee72ea-15ae-45ce-b0f5-611c4f8d4a71
Key1: d3e90afc-0f09-4054-9bac-350cc8dfc901
Key2: 7cee72ea-15ae-45ce-b0f5-611c4f8d4a71
-
- Official SamyGO Developer
- Posts: 1700
- Joined: Fri Oct 02, 2009 8:52 am
- Location: Austria/Vienna (no Kangaroos here)
- Contact:
Re: LNxxB650 and B679 with CI+ certification
you can save your time, i think the key come from hardware.gafe wrote:...
Today I will repeat the tests with openssl, making a bash script to test all cypher types of openssl (des,rc4,etc.)
by the way:
copy the exe.img.sec into the same dir as the script (look at txt-file locations!)
check the output also!
script needs 1 argument (exe or appdata)
Code: Select all
#!/bin/sh
# 54251812
# enc -aes-256-cbc
# enc -des3
ENDE=$(stat $1.img.sec | grep Size: | cut -d ":" -f2 | cut -f1)
SHORT=$((${ENDE} - 260))
F_NAME=$(basename "$1")
# F_NAME="appdata"
# for i in `seq 0 $ENDE` ; do
# for i in `seq 0 1024` ; do
# for i in 1008 ; do
echo "$1 : ${ENDE} -> ${SHORT}"
dd if=${F_NAME}.img.sec of=/${F_NAME}.img.sec.cut bs=${SHORT} count=1
dd if=${F_NAME}.img.sec of=/${F_NAME}.pass bs=${SHORT} skip=1
dd if=${F_NAME}.img.sec of=/${F_NAME}.raw-pass bs=1 skip=${SHORT} count=259 # skip lf at end
dd if=${F_NAME}.img.sec bs=8 skip=1 count=1 | xxd -p > /${F_NAME}.salt
DIG='aes-128-cbc aes-128-ecb aes-192-cbc aes-192-ecb
aes-256-cbc aes-256-ecb base64 bf
bf-cbc bf-cfb bf-ecb bf-ofb
camellia-128-cbc camellia-128-ecb camellia-192-cbc camellia-192-ecb
camellia-256-cbc camellia-256-ecb cast cast-cbc
cast5-cbc cast5-cfb cast5-ecb cast5-ofb
des des-cbc des-cfb des-ecb
des-ede des-ede-cbc des-ede-cfb des-ede-ofb
des-ede3 des-ede3-cbc des-ede3-cfb des-ede3-ofb
des-ofb des3 desx idea
idea-cbc idea-cfb idea-ecb idea-ofb
rc2 rc2-40-cbc rc2-64-cbc rc2-cbc
rc2-cfb rc2-ecb rc2-ofb rc4
rc4-40'
function guess() {
echo "ok with $2"
mv -vf $1 $1$2$(date +%s)
}
for i in $DIG ; do
echo "digest -> $i"
# done
# while true ; do
# let ENDE-=1
# let i+=1
# echo "cut down $i bytes from ${F_NAME}.img.sec ($ENDE)"
# dd if=${F_NAME}.img.sec of=${F_NAME}.img.sec.cut bs=$ENDE count=1
# dd if=${F_NAME}.img.sec of=${F_NAME}.img.sec.cut bs=$i count=1
openssl $i -d -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -k T-CHUCIPDEUC
[ "$?" -eq "0" ] && guess /${F_NAME}.img $i
openssl $i -d -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass pass:T-CHUCIPDEUC
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass pass:A435HX
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:./info.txt
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:./version_info.txt
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:./serial_temp
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:/${F_NAME}.pass
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:/${F_NAME}.raw-pass
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -salt -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -k T-CHUCIPDEUC
[ "$?" -eq "0" ] && guess /${F_NAME}.img ${i}-salt
openssl $i -d -salt -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass pass:T-CHUCIPDEUC
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -salt -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass pass:A435HX
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -salt -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:./info.txt
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -salt -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:./version_info.txt
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -salt -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:./serial_temp
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -salt -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:/${F_NAME}.pass
[ "$?" -eq "0" ] && echo "ok with $i"
openssl $i -d -salt -in /${F_NAME}.img.sec.cut -out /${F_NAME}.img -pass file:/${F_NAME}.raw-pass
[ "$?" -eq "0" ] && echo "ok with $i"
done