Sony NEX/Axx Firmware hacking

Nex-5n here.

UART0 shows the following just after the camera is reset for a firmware update, haven't gone further as it won't be possible to revert to older firmware once I do:

Code: 
E
Uncompressing Linux.......................................................... done, booting the kernel.

relevant FirmwareUpdater.log

Haven't looked at UART1 or JTAG yet (crash course welcome on JTAG, have not used it before)

Also booting with BOOT_MODE_1 high results in no serial output and the SD card light flashing on and off at about one second intervals. Not sure what it's waiting for here.
 
I have been doing some research couple of months ago and i want to continue when i have the time (~mid june).
I backed up all of the fw version so if anyone is interested pm me
 
A comparison of the VG-20 and other NEX camera FW's would be handy i'm sure in adding clean hdmi to the nex 5n, and nex 7. VG-20 allows clean HDMI and shares very few tecnical differences apart from case size. hardware is near identical
 
Just clean live view HDMI in Nex5n is my only real request, that, and a Sound Devices PIX 220 can make the NEx5n a little great FS100 ;) at $2500, obviously this will kill the VG20 for good.

Ahhhh.. dreaming..
 
Just want to heat up the thread.
The firmware is a single tar in ustar format with standard initrd.img, vmlinux.bin, rootfs.img, standalone libraries and something that manufacturer calls scenarios. The last one are probably UI description. They are gzipped. Files starts with ESFf and has esf extension.
 
I can't find the ustar/gzip header anywhere in the FirmwareData*.dat. How are you extracting these files?
 
someone1.00 said:
Just want to heat up the thread.
The firmware is a single tar in ustar format with standard initrd.img, vmlinux.bin, rootfs.img, standalone libraries and something that manufacturer calls scenarios. The last one are probably UI description. They are gzipped. Files starts with ESFf and has esf extension.
Click to expand...
How firmware is encrypted?
 
rdrr said:
I can't find the ustar/gzip header anywhere in the FirmwareData*.dat. How are you extracting these files?
Click to expand...

I don't say anything about gzip headers or even it's signature in firmware. And it's not a secret that FirmwareData_user_xxxxxxx_loader.dat is not a firmware itself. Its a container and even encrypted firmware file lay inside it not in a simple way. And sure you will not find any plain text in crypted firmware.
About encryption. I cannot tall anything about it at this moment.
 
someone1.00 said:
I don't say anything about gzip headers or even it's signature in firmware. And it's not a secret that FirmwareData_user_xxxxxxx_loader.dat is not a firmware itself. Its a container and even encrypted firmware file lay inside it not in a simple way. And sure you will not find any plain text in crypted firmware.
About encryption. I cannot tall anything about it at this moment.
Click to expand...
If you cannot decrypt the FirmwareData file, where did you get the information about the tar format, *.img's and scenarios? It sounds right, but how did you discover it?
 
rdrr said:
If you cannot decrypt the FirmwareData file, where did you get the information about the tar format, *.img's and scenarios? It sounds right, but how did you discover it?
Click to expand...

It's better than truth its how it is :) I can access decripted files from firmware.
 
I’ve finished with my investigations. At this point I have two ways. Modify the firmware for myself or share the algo and the key. In last case I want to try to decrypt a77 firmware. The algo I know is not compatible with it, nex5n, a57 and 65. I need to be donated to be able to buy nex 3 a77 and nex 5n. If any community will be able to support me I will share algo and key.It can decrypt any nex 3, nex 5 firmmwares, VG10, a33 and a55. I can create a windows executable that will take an updater files or an updater itself and extract firmware from it. I can prove my knowledge in any way. I can suggest to open a small middle part of a firmware (one means any) not less when 1K and not too big. But it’s only a suggestion.
Here is a short video https://rapidshare.com/files/2428685917/Video5.avi
fw.tar is a part of the firmware I’ve talked earlier. The end of archive warning is a 7z warning. The tar is pretty solid for me but probably not finished with proper empty spaces. I found this right now and don’t want to lose a time to investigate. I've browse some files structure (full listing is below) and extracted most interesting images. I’ve used some commercial software to assure it’s not a fake screen. And yes I can create such fake tar but content of the linux images looks pretty fine for me. You can see headers and different notes… I’ve searching for sony word inside it.
Below is a file/directory list from some firmware
usr2
usr2/data
usr2/data/sound
usr2/data/BEEPDATA.BIN
usr2/data/scenarios
usr2/data/scenarios/app_cwb_snr.esf
usr2/data/scenarios/app_rec_snr.esf
usr2/data/scenarios/app_uud_snr.esf
usr2/data/scenarios/app_eps_rsf.rsf
usr2/data/scenarios/app_repair_snr.esf
usr2/data/scenarios/app_palette_snr.esf
usr2/data/scenarios/app_movie_rec_snr.esf
usr2/data/scenarios/app_stg_snr.esf
usr2/data/scenarios/app_hdmi_snr.esf
usr2/data/scenarios/app_play_snr.esf
usr2/data/scenarios/app_dlg_snr.esf
usr2/data/scenarios/app_rhg_snr.esf
usr2/data/scenarios/app_dds_snr.esf
usr2/data/scenarios/app_usb_snr.esf
usr2/data/scenarios/app_top_snr.esf
usr2/data/scenarios/app_menu_snr.esf
usr2/boot
usr2/boot/initrd.img
usr2/boot/vmlinux.bin
usr2/boot/rootfs.img
usr2/ex_conf_223.h
avsys
avsys/av.bin
avsys/sa_srec.bin
avsys/ancy_ipl.bin
avsys/ancy.bin
boot
boot/GPS
boot/ACCY
boot/factory
boot/factory/Asys.bin
boot/factory/initreg.bin
boot/factory/Hsys.bin
boot/factory/ex_cnf.bin
boot/cas
boot/cas/CA_FROM.BIN
boot/cas/CA_FRAM.BIN
boot/cas/BRD.bin
boot/backup
usr
usr/log
usr/bin
usr/bin/mpr_monio
usr/bin/app
usr/bin/app/main.sh
usr/bin/app/deviceInfo.xml
usr/bin/app/main
usr/bin/app/haif.ko
usr/bin/app/serr.ko
usr/bin/app/main3.sh
usr/bin/debugio
usr/bin/mpr_viewLog
usr/bin/memtool
usr/bin/sen
usr/bin/usr_up
usr/bin/testcmd
usr/bin/debugio_core
usr/bin/ud_datcnv
usr/bin/av_conio
usr/bin/up
usr/lib
usr/lib/libadj30.so
usr/lib/libpro00.so
usr/lib/libadj33.so
usr/lib/libwtle.so
usr/lib/libSnr.so
usr/lib/libosal.so
usr/lib/libcmdcmm.so
usr/lib/libadj36.so
usr/lib/libBackupTable.so
usr/lib/libusbcmd.so
usr/lib/libul_debug.so
usr/lib/libadj32.so
usr/lib/libpro01.so
usr/lib/libadj31.so
usr/lib/libadj37.so
usr/lib/libul_xml.so
usr/lib/libpro11.so
usr/lib/libBackupCore.so
usr/lib/libusb.so
usr/lib/libdebugprintf.so
usr/lib/libgps.so
usr/lib/libadj34.so
usr/lib/libAppBackupApi.so
usr/lib/libupdatercommon.so
usr/lib/libsencore.so
usr/lib/libitype.so
usr/lib/libupdaterapi.so
usr/lib/libAppSenserApi.so
 
Hey that's pretty fantastic! How did you find the algorithm and key? Annoyingly I only have a 5n to play with so I'm still investigating, though I think you should share your methods anyway because it might help ;D
 
rdrr said:
Hey that's pretty fantastic! How did you find the algorithm and key? Annoyingly I only have a 5n to play with so I'm still investigating, though I think you should share your methods anyway because it might help ;D
Click to expand...


I will share it only if i'll be sure it will not work for older firmware versions. This will not lat manufacturer to prevent this. And yes it can be prevented very simple. And one more thing... It took almost a year to crack it. And will not be much faster second time from the beginning.
 
So how can we help? What is your plan moving forward? Are you planning on releasing the freed firmware to the community once you've verified it will work with all existing models?

someone1.00 said:
I will share it only if i'll be sure it will not work for older firmware versions. This will not lat manufacturer to prevent this. And yes it can be prevented very simple. And one more thing... It took almost a year to crack it. And will not be much faster second time from the beginning.
Click to expand...
 
You must log in or register to reply here.
Back
Top