• Content count

  • Joined

  • Last visited

Community Reputation

1 Neutral

About HuangYe

  • Rank
  1. now, I'v bought DS918+ , but I am still interested in hacking DS918+
  2. @x01015918 the table like "0000 0700 1b4b9235 ahci" , this is syno daemon used to check special table for allowed devices and compares it with strings in /proc/bus/pci/devices. (thanks to @Vortex ) 1b4b9235 stand for vendor id and product id. in this case , it is 923588SE9235 PCIe 2.0 x2 4-port SATA 6 Gb/s Controller (this info get by visit ) so ,every syno product has specific pci vendors. syno has a table, it just check if the real pci devices in Linux system is exists in the table. if some devices not found, then, syno DSM system can know that, it is not running under the official syno hardware. According to previous research, If more than two devices are not found in /proc/bus/pci/devices, then drives off. plz ref to this thread: for example , gnoboot hack dsm 5.0 : related shell script: #!/bin/sh source /etc/rc.subr source /.gnoboot/rc.init [ -d "${gnoBoot}" ] || exit 1 gnoBootMountPCI() { if [ -f ${gnoBoot}/devices-append ]; then if [ `grep -c pci/devices /proc/mounts` -eq 0 ]; then /bin/cp -f ${gnoBoot}/devices-append /tmp/.devices cat /proc/bus/pci/devices >> /tmp/.devices /bin/mount -n -o bind,ro /tmp/.devices /proc/bus/pci/devices fi echo "Re-generating missing device nodes..." >> ${gnoLogFile} SYNOGenAllDeviceNodes fi } gnoBootMountPCI gnoBootRegen exit 0 I think that Jun's patch implement this in a similar way
  3. I think the flow may like this: grub loader => load the orig linux kernel => initrd rd.gz extra.lzma extra.lzma replaced the original init file with it's own. (the new init file will patch syno config files in rd.gz and then run the real init program provided by busybox) seems that, the magic modprobe will run in /usr/syno/hotplug/hotplug.functions (hotplug.functions(69): MODPROBE="/sbin/modprobe -s") but I dit not find /sbin/modprobe in rd.gz so, it it like @Polanskiman @IG-88 said, the work was done in modprobe if you load modprobe in IDA pro. you 'll see nothing but a _start() function. it is hard to reverse engineer Jun's hack
  4. I mailed Jun, but got no response. so , I don't know if he has time to hack 918+ himself or help us hack 918+. hope Jun can do this for us.
  5. @Polanskiman @IG-88 thank U very much. This information is very helpful to me
  6. I think synoupgrade is for system upgrade. not for pure installation. after analyze the /usr/syno/bin/scemd (install.cgi) . I found the all the installation process was done in this file. also the err_patch error was generated by it: {"success": false, "data": {}, "errinfo": {"sec": "wizard","key": "err_patch","line":13}} which translated to text is: "Failed to install the file. The file is probably corrupted. (13)"
  7. thanks, I'll come to see the "magic" modprobe file. for kernel 4.4, you need to remove the O=xxx param in the build script.
  8. the modprobe is just a binary program to load needed kernel module . I do not think there's hacking tech in the file. also, I investigated jun's ds3615xs patch, the VERSION file in rd.gz shows that: majorversion="6" minorversion="1" productversion="6.1" buildphase="GM" buildnumber="15047" smallfixnumber="0" packing="repack" packing_id="1" builddate="2017/02/18" buildtime="19:43:05" unique="synology_bromolow_3615xs" extractsize=712716 so, I downloaded the original pat file: compare the stock kernel image: hacklog  …  ds3615  extract  DSM_DS3615xs_15047  file zImage zImage: Linux kernel x86 boot executable bzImage, version 3.10.102 (root@build1) #15047 SMP Thu Feb 23 02:24:19 CST 2017, RO-rootFS, swap_dev 0x2, Normal VGA to which jun's : jun's kernel: hacklog  …  ds3615  extract  part2  file zImage zImage: Linux kernel x86 boot executable bzImage, version 3.10.102 (root@build1) #15047 SMP Sat Feb 18 17:34:10 CST 2017, RO-rootFS, swap_dev 0x2, Normal VGA so , I guess the only possible hack might be in the kernel (or extra modules). the "rd.gz" file in stock pat file and jun's patch are both the same. so there's nothing to do.
  9. Thanks @liwei 's github repo. which help me a lot .
  10. currently I bought asrock j4205 mb and in-win ms04 chassis. I found that DS918+ 's CPU is j3455 (which is close to J4205). but there's no hack loader. so I mod the loader from Jun's ds916+ loader (v1.02b). I download the dsgpl kernel code: 4.4.15 version (which is the kernel used in 6.1.4 synology dsm) use this scripts: I build the kernel with following change: cp synoconfigs/apollolake .config Define XPENOLOGY macro tty: Enable virtual console .config: Enable more SATA controllers. Enable more ethernet drivers. Add kernel parameters to customize synoboot pid & vid. (support pid= and vid= ) config: Add support for OHCI driver Fix function exporting. - syno_libata_index_get disable write to GPIO in syno_sata_mv_gpio_write / syno_sata_mv_gpio_read function. ... also, I mod the grub.cfg , set the right vid and pid and mac1. also I change grub command param to: syno_hw_version=DS918+ then replace the extra.lzma of ds916+ loader (v1.02b) with the new generated jun.lzma and replace zImage with the build one. replace rd.gz with the one extracted from the newest ds918+ pat file. than I write to my sandisk USB disk and it boot successfuly. but when I upload the ds918+ pat file (the file is OK,I calculated the md5 checksum). when the upload is done, it start the installation and just failed. I got some related request and response from chrome dev tool: {"success": true, "data": {"stage": "install"}} {"success": false, "data": {}, "errinfo": {"sec": "wizard","key": "err_patch","line":13}} I do not know what the error "err_patch" mean. the web ui said that "Failed to install the file. The file is probably corrupted. (13)" , but I'm quit sure that my VID/PID is correct. pat file I used: I know that this error information was generated by /usr/syno/bin/scemd (install.cgi) I disambled the scemd elf file use IDA pro, but code is hard to read, and I can not find which function call get the "err_patch" error.