Collaboration with samsung-nx-hacks

[ge0rg]

Hi,

this is a great overview of what's possible with the high-end NXes, awesome job!

I'm the author of the Hacking the NX300 series and the janitor over at https://github.com/ge0rg/samsung-nx-hacks and I'd really like to merge the efforts.

I don't have much time to maintain the wiki, but I'd gladly give write access to the repository, or cooperate in any other meaningful way. There was some work on the NX300 front, especially reverse-engineering of the remote viewfinder protocol, that could be applicable when writing 3rd party remote-control apps....

Kudos,
ge0rg

[ottokiksmaler]

Thank you for your kind words, it was your work on NX300 that prompted me to do this :)

I agree the should be a single place for all things NX and I'm open for any kind of cooperation. Some of these "hacks" should work with older models as well, but we need someone to test them out.

[ge0rg]

I've got the NX300 as well as the 500 now. From a quick glance, the open source package for the 500 doesn't look as complete (there are packages and kernel, but I haven't identified the closed binaries yet.

There is a browser widget in the rootfs of the 500, maybe we can get something comparable to https://github.com/ge0rg/samsung-nx-hacks/wiki/WebBrowser to work?

P.S: I've added you as a collaborator to samsung-nx-hacks, feel free to contribute :)

[ottokiksmaler]

Browser works out of the box, just start it from telnet session :)

[ge0rg]

Nice! The keyscan code looks very interesting for NX300 as well... I've made some attempts at hijacking key events to turn off the OLED here: ge0rg/samsung-nx-hacks#4

However, it just didn't work out when launching from autoexec.sh. Also played around with "time-lapse photography" using shell scripts with st key & sleep...

It's also awesome to see that / and /opt are etx4 file systems, allowing for evil in-place manipulations... the NX300 rootfs wasn't writable :(

[ottokiksmaler]

Opt is already rw, there is even a path from it in the system path. Changes survive reboot.
Root can be remounted as rw, it works and nothing bad happens :)
OTOH, camera does not actually boot, it resumes from mmcblk0p9 swap partition so all changes I did to systemd made no effect. I'm still kinda scared to mess with suspended image (it's zswap, there's also zram but it's empty and not actually used for anything, it seems).
The thing I really want to do is start a shell script from SD card without entering the factory mode (as it disables a number of functions like Bluetooth, partially touchscreen, etc).

[Tommixoft]

Otto did you tried replacing NX500 camera/video record app with NX1? maybe all good stuff from nx1 is just in a simple app?

[ottokiksmaler]

No. Di-camera-app controls everything (as in if you mess it up you're bricked) but does almost nothing (it just issues commands to RTOS that does the real work). And there are plenty of differences between nx500 and nx1 for me to stay clear (different layout and contents of prefman, different memory offsets, etc). Just an illustration, di-camera-app knows nothing about rolling shutter.

[Tommixoft]

hmm how it's possible to brick OS just for 1 app? i mean telnet stops working? i think you could always restore original. But as i can see-for linux noob like me -better stay away and wait till someone smarter finds something...and i wanted real bad to help on this.

[ottokiksmaler]

You cannot just replace di-camera-app as it's running before your script (it actually starts your script). You would have to replace it in the filesystem and suspend file then reboot, and since it's also responsible for flashing and updating the firmware if it does not work you cannot reflash the original firmware. Bummer.
And since I had to travel ~500 miles just to buy nx500 and even that store does not carry Samsung cameras and noone in my or even neighboring countries services NX cameras there's no way I'm messing with it.

[Tommixoft]

OMG.... thank for info... as i see you learn it hard way.!! this would be first thing i planned to do when i get my nx500! you saved me. thanks. :)

[ottokiksmaler]

Your best course of action is to use debugger and first try to suspend the process with pid 247 (this works, gdb will pause it as soon as it attaches), change the memory (works in gdb for individual memory locations, did not try with complete process) and continue the process (also works, gdb detaches and continues it). It works from command line as well (kill for suspend and continue, anything for writing to RAM). Sizes of executables are different, process state will be different (stack, etc), program counter would be pointing ... somewhere else... Etc. You will miss a lot. At least any change is gone by simple reboot.
Also, this process starts many other processes, due to toolkit used, even individual pieces of gui are running as separate processes, settings app is also separate...

[Tommixoft]

Wow you spend a lot of time on this. Thanks for this. so many people just waiting to get things not even knowing how much work required to accomplish even sometimes simple looking things. Im developer for windows but even that doesn't help me with linux :) Im shitty programmer i use .net framework and everything is so easy :) Will go and read on gbd. really hope tomorrow get camera and start tests.
Anyways you already made my biggest wish come true- 2.5k video :) Rest would be full size 4k cause Nx1 MUCH better 4k than nx500.

[ottokiksmaler]

Unfortunately this has nothing to do with normal programming, we are disassembling executables and libraries that are stripped off of their symbols with no documentation, etc. This is as far removed from normal development as you get. So it takes longer, much longer.
If Samsung had released any kind of SDK for the camera it would be almost trivial by comparison (and I'm sure their sales would be better, but hey, they know what they are doing, I'm just a random guy from the Internet).
Regarding 2.5k we're waiting for Vasile and higher bit rates hack to make a decent gui and wrap something up.

[Tommixoft]

this camera needs something like in android - recovery loader so be able to copy whole system and restore on fail :D

Also i saw you wroye focus possition app. i think you could use this knowledge and write simple gui in which people could have their functions and see like buttons. So we only could call your app instead os scripts. in your app there could be most used functions. Lets say-enable 2.5, enable DIS or something like this. you could even read text file and people could add their entries based on your format so you could make menu of it.

[ottokiksmaler]

I'm actually planning to do exactly that - like a control panel with several buttons, but I need first a robust method of setting the bitrate for video. I have some small tools that I'll release soon-ish for people willing to do something more on their own - popup boxes, input boxes, etc, that can be used from shell.

[ge0rg]

I've read through the markdown files in the repo now, and there are some gems.

Is there any documentation of the boot process / filesystem layout (I LOLed that it is a regular partition table with over a dozen partitions)? I'd really like to see that documented as well. Should I write some more .md files and send pull requests?

[ottokiksmaler]

I have added you as collaborator, I guess it's easier that way.
Partitions are as follows:

[root@drime5 ~]£ cat /etc/parttab 
£ nx500 partition table
£ <vol>       <dev>       <size(M)>        <image>  <order> <compress>  <fs>  <mkfs-option>  <mount-point>
£
adj           /dev/mmcblk0p1     20             none   1    None        raw
rtos          /dev/mmcblk0p7     30          rom.bin   2    None        raw
rtos_data     /dev/mmcblk0p8     50             none   3    None        raw
£extended     /dev/mmcblk0p4      0             none   4    None        raw
platform      /dev/mmcblk0p10  1024       rootfs.img   5    LZO        ext4
opt           /dev/mmcblk0p11   100          opt.img   6    LZO        ext4      -j              /opt
pref          /dev/mmcblk0p2     10             none   7    None        raw
pref_default  /dev/mmcblk0p3     30 pref_default.bin   8    None        raw
pref_recovery /dev/mmcblk0p5     20             none   9    None        raw
opt-usr       /dev/mmcblk0p14     0             none  10    None       ext4      -j              /opt/usr
rImage        /dev/mmcblk0p13    10           rImage  11    None        raw
pcache        /dev/mmcblk0p12     5      pcache.list  12    None        raw
devicem4      /dev/mmcblk0boot1   4     devicem4.bin  13    None        raw
snapshot      /dev/mmcblk0p9    100     snapshot.img  14    LZO         raw
uImage        /dev/mmcblk0p6     10           uImage  15    None        raw
bootloader    /dev/mmcblk0boot0   4   bootloader.bin  16    None        raw

[ottokiksmaler]

Main thing iz zswap partition used for hybrid sleep as the camera never actually boots - it just resumes (it's present in the firmware image prepopulated as well).