neXus

Tss bad mood for now... Forum is here to share idea and knowledges

In fact my release works fine but I think I will keep it for me for several reasons : 1/ syno put some verification so they don't want the dsm been installable on a cheaper system. 2/ if it spread on the internet as a ready to use release, syno will certainly add more check in next release. 3/ all on this thread give enough information to create your own working system. 4/ I don't recommend dsm for kiddies as update could break the system 5/ the kernel modification need to be included if they update the kernel and I don't want to be the maintainer. 6/ it's easy to create a Trojan horse release, with backdor in it, that's why I create my own release from scratch. As it's a borderline project, I suggest to only install code you can trust. So to sum up its great if you are familiar with Linux and understood all of the things in this thread. Dsm check can be defeated for the moment. I take responsibility on my own hardware if it failed, I never support this release for others. For a production usage, you should consider using openmediavault/freenas/openfiller. Maybe if I am in a good mood I will post my synoboot img used to install genuine pat files.

It's runs for about 48h on my brand new N54L. Installed from PAT, update done to latest. USB device protected by sinology mechanism (I can also change my boot kernel / parameter within the running system without breaking anything). I don't have any bios bad checksum issue (but I didn't played with the scheduled function or WOL). It works fine, but need more test. During my tests, I discover that other .cgi are doing some "device check test". When it occurs, you must recreate all block nodes described in /proc/partitions. I aslo experience some issue, where the volume crashed (but goes back after reboot). Or some issue regarding the monitor status regarding the network device (fixed by a reboot too). So it's not ready for production unless you are familiar with DSM internal to get through theses issues. I recommend stay on 4.2 for the moment.

Well it use a module in order to have direct memory access through the kernel. A binary is then used to fetch information and flash updates. It is "possible" but need a lot of work. I try to find a workaround... EDIT : As a workaround, let DSM download the files, go to /volume1/@smallupd@te_deb, un pack the flashupdate deb, replace updater with a shell script 'exit 0', repack, replace and push the button. I can easy be scriptable. The flashupdate is here to update synoboot, but we don't care. Note : it may break your DSM, I suggest you to try on a virtual machine before. I update from 3776 to 3776-3 and everything is working fine.

Yes same stage, it loads a module in order to flash the bios and fail. Edit : Monod is not needed for me a my USB stick is reconized as synoboot device.

Il faudrait que : Soit lacpi soit implémentée pour envoyer un proper shutdown au système Soit que l'action du bouton envoie un ordre via le port série ttyS1 Pas simple en somme Sur les syno tout est gèré via le port série apparemment, led et boutons via un contrôleur dédié. Contrôleur que nous n'avons pas sur le n54l. Par contre on doit pouvoir faire notre propre drivers n54l -> serial mais y'a du boulot....

The process use a dedicated module inside the PAT file, and also use /dev/mem... will be hard to fool. The updater process is also inside the PAT file.

Well, Dealing with autoupdates, it tries to update the bios (which failed), no idea if we can deal with as the updater process is in the PAT firmware downloaded. It means, upgrade may work with synoassistant or we need to strip some informations from PAT upgrades and feed the DSM with it...

http://www.synology.com/support/tutoria ... p?q_id=485

Booting on HDD is not possible as drives are parts of a raid array. I know why it failed my synoboot contains only one partition. I have to find the layout of a real synoboot and the contents. We don't have the source of the updates by the way. For the symlink issue it's weird as my volume is empty - fresh install - I will keep you posted.

Just remove the rmmod from linuxrc / updater.sh in the initrd do the same thing. I have something weird, It said the system volume has crashed, it is fixed by a reboot but sometimes it appears again... I found this weird thing in messages : storagehandler.cgi : raid_disk_create.c:88 failed to fopen /sys/block/md1/md/dev-sda2/slot, errno=Too many levels of symbolic links Is anyone already seen that in previous DSM ? (I can't tell DSM4.3 is the first one for me). NOTE : I try an upgrade to 3776.3 we will see EDIT 2 : woops Oct 15 21:12:22 DiskStation updater: updater.c:4197 The SynoBoot partitions exist. Oct 15 21:12:22 DiskStation updater: updater.c:2413 SYNORedBootUpdCheckAndApply(2413): Skip bootloader update, no uboot_do_upd.sh exists Oct 15 21:12:22 DiskStation updater: boot_lock.c(224): failed to mount boot device /dev/synoboot2 /tmp/bootmnt (errno:6) Oct 15 21:12:22 DiskStation updater: updater.c:4293 fail to unlock boot partition Oct 15 21:12:22 DiskStation updater: updater.c:4537 Failed to accomplish the update! (errno = 21) I will need to dig this one too.

So we are at the same state for now with maybe two different approach. Could be nice to discuss it in pm

ttyS1 simulation or just removed the unload line from linuxrc ?

I just added two more kernel parameters to pass pid/vid of a device considered as a "synoboot USB flash" device. No more synoboot erased and the stick doesn't appear either in file station or Storagemanager

It seems, I just installed surveillance station, Volumes are still here.

Seems fine

Finally got it. it's a kernel patch overriding the devices seq_file if specific processes try to open it. Works like a charm I need to make some tests but sounds promising cat scemd.trace.7833 |grep -E "open\(|unlink" [f6f1ccbb] open("/usr/syno/etc.defaults/dnsdsm", O_RDONLY) = 8 [f719fd6b] open("/dev/urandom", O_RDONLY|O_NOCTTY|O_NONBLOCK) = 9 [f6f1ccbb] open("/proc/self/comm", O_RDONLY) = 9 [f719fd6b] open("/usr/syno/bin/findhostd", O_RDONLY) = 11 [f719fd6b] open("/usr/syno/synoman/webman/modules/StorageManager/storagehandler.cgi", O_RDONLY) = 11 [f719fd6b] open("/usr/syno/synoman/webman/modules/StorageManager/volumehandler.cgi", O_RDONLY) = 11 [f719fd6b] open("/usr/syno/synoman/webman/modules/PkgManApp/PkgMan.cgi", O_RDONLY) = 11 [f719fd6b] open("/usr/syno/synoman/webman/modules/PkgManApp/PkgSynoMan.cgi", O_RDONLY) = 11 [f719fd6b] open("/usr/syno/synoman/webman/modules/DSMNotify/dsmnotify.cgi", O_RDONLY) = 11 [f719fd6b] open("/lib/libdsm.so", O_RDONLY) = 11 [f719fd6b] open("/lib/libsynocgi.so", O_RDONLY) = 11 [f6f1ccbb] open("/proc/bus/pci/devices", O_RDONLY) = 8 [f6f1ccbb] open("/etc.defaults/synoinfo.conf", O_RDONLY|O_LARGEFILE) = 9 [f6f1ccbb] open("/etc.defaults/synoinfo.conf", O_RDONLY|O_LARGEFILE) = 9 -> no unlink

That's why I'm working on a patch kernel side. As we have to use a custom kernel, it makes senses to tweak it for that purpose. I don't find yet why when hooking/redirect the open syscall scemd is getting the real device file (maybe it use inode to map the file to memory I don't know). It's harder than we thought but not impossible.

Thanks got that one already good stuff in here.

Hmm removing the entry could have side effect if other processes try to gather information about it.

Here too I'm kind of busy theses days so I can only spend halt an hour max to play with... @Venom, did you filter the open hook on current->comm (process name), I mean there could be side effect if all of the open are hooked to the fake file we juste have to build an array with all of the process name calling for it (hoping no side effect) and compare with current->comm. Another thing, I got issue with ia32_sys_call_table at first (because of 64 bit architecture and 32 bits binaries), I made an ugly "hack" (#define __NR32_OPEN = 5), how did you deal with ? If you can share your code I can also share mine. Tanks. I started to look to emulate the ttyS1 device for for example the get_micropid() function with a proper return, it could be easy to do. In fact binaries like scemd use ioctl to /dev/synobios and synobios.ko deal with /dev/ttyS1 (with is a serial device to manage leds, button,...). the module contain also some kernel function to deal with satacontrol and disks. So with a little work, we could : Generate a custom synoboot from pat file : - get the rd.gz and add the module to fake the system (need to be added before synobios.ko) - add a custom kernel for better compatibility (64bits / drivers) Install the DSM from the genuine PAT file without any patching or rebuilding. This way we don't "break" any Synology property.

Thanks it has been fun !

I agree it's syno property. @vortex did you check my pm ? Thanks

I dont think so as in the dump we have the memory dump with shared objects in it. It's more the memory program (un packed). It's like rebuild the the windows kernel from a bsod kernel dump. No need to repack we found the way to fake the system to make it believe it's a genuine one (except for synobios which still need to be patched).

It's a core dump when a process crash. That's from it we found some clues.