Leaderboard

powerbutton for DSM7 (apollolake and bromolow): https://www.file-upload.net/download-14659361/install.sh.html https://www.file-upload.net/download-14659363/powerbutton-7.0-apollolake.tar.html https://www.file-upload.net/download-14659362/powerbutton-7.0-bromolow.tar.html

ThorGroup is working on

The RedPill is back! As some of you may be aware a lot of research materials as well as the code for parts of the kernel module were pulled from GH. We're happy to report it's back and fully public! Before further ado we have a small sneak-peek of the current state: Repositories Both LKM code and the research materials are present in two repositories. Both are automatic forks from our internal serves and are updated few times a day. - RedPill LKM: contains the current version of the Linux kernel module source code along with implementation details description - DSM Research/Docs: hosts documentation for developers regarding the inner details of DSM boot process While the dates and authors in both repos are anonymized, the history is preserved. Thus, your forks and PRs will work properly. The Current State As of now the DSM installs & boots properly (sort of, continue reading). We are currently working on a toolset for generating the loader image automatically so that testing new iterations is easier for people not familiar with full inner workings of the kernel component & the bootloader itself. The tool with instructions will be published in a separate repo. The kernel module is currently missing the PCI-IDs shimming and RTC emulation. While the latter is most likely not crucial, the former must be implemented. However, it's not really straight-forward as naturally the kernel doesn't have a high-level API to lie about nonexisting hardware The current revision of the LKM causes some errors to be sent to the PMU. If anyone in the community (@Vortex? @IG-88?) has an idea of what is the source of these we will be grateful for some pointers. --R--R-p--R-4 -9 --R-r-K-8-3-8 As of now we're working on a robust PCI emulation layer. This isn't hard in theory but has many pitfalls if we want to do it properly and none of us ever studied inner workings of PCI on x86 As described in the PCI document in the research repo there are three methods. We picked the third one (full PCI emulation) as it allows for creation of devices which are indistinguishable from real ones. While this is the hardest to pull off properly, it doesn't rely on a hack but rather an official and documented Linux API. Q&A Who are you? We're a group of passionates dating back to the (great) phreaking times. If you know where to look you will find us on IRC Can I get involved in the development? Yes! As this project took a lot from the community we strongly believe it should continue to be shared and developed under GPL. We greatly appreciate any PRs on GH. I'm not a developer, can I help? At this stage most likely not. However, we wish to have some testing version not too far in time. For various reasons we cannot (and not willing to) accept any donations. If you want to make us feel better leave a like and a good word for us, as naturally this isn't our full-time job :))) Why is making the code public matters? We believe that the code of the loader MUST be public. We aren't sure if the general community is aware of the degree of control the "loader" has over their box. Despite the name it is not just a load-and-leave situation. The majority of the loader code is active in the system for the whole time (you can check that by doing lsmod and looking for an entry which doesn't look like a proper module name but one or more random characters). The kernel module can do literally anything you can as root... and more. It can read files, send them in the background somewhere, hide files from you, execute programs with higher-than-root privileges without showing them in any tools, use your CPU while showing 0% in htop etc... and the worst part is that you will never know that it happened (unless you're monitoring your device from the outside). However, after this scary paragraph we can say two things: Jun's loader doesn't seem to do any evil things, and the actions any loader needs to perform in the system after the initial load are minimal (e.g. fake responses to "turn on HDD led"). We've also reviewed the code we cloned and it's a solid base. Additionally, making the code open means anybody can tinker with it and adjust to new scenarios instead of relying to bit-patching a .ko. What happened to previous repos? Are you crediting the previous author? The author of the original code wishes to distance himself from the project and we are respecting that. That's all we know. Do you/anyone have the code of Jun's loader? We saw that there's some confusion on the forum regarding Jun's loader and why the work had to start from scratch. Neither the Jun's loader code nor any deeper implementation details regarding inner working of his amazing loader were ever shared with the public. We weren't able to obtain the code through our sources either. There's a good chance he never shared the with anybody. Is Syno trying to block the loader? While we cannot comment on any actions, we can surely talk about the code. The new kernel contains something which isn't present before 25556: https://github.com/RedPill-TTG/dsm-research/blob/master/quirks/boot_params-validation.md It is true that the "va not found" error triggered by the Jun's loader when used with >6.2.3 is indeed related to offsets which changed in the new build. However, the rabbit hole doesn't stop there. The new "boot_params" check doesn't seem to have any other purpose than detecting violation of the chain of trust. So did the new kernel build broke the loader intentially? Most likely not (it's probably a by-product of the new validation code present very early in the image) but why the boot params validation was placed in 6.2.4 in the first place? We leave the interpretation to the reader. When we can expect a stable release? Will it work on v7? We cannot promise any date for two reasons: 1) we can hit an unexpected roadblock (e.g. see errors mentioned above), and 2) we will like to test it and have it working on v6.2.4 and v7 as well (as of now v7 is available for selected devices only and from our tests it is not fully stable even on the devices it was officially released). Some of the protections found in v6 were pulled from v7... but don't worry, they will be back as soon as they port them... it's a carrot and a stick situation. cc for people who followed the original topic: @AleAmadoC @alexku44 @Amoureux @Balrog @blindspot @Bobbenoster @Bobur @coolinx @dimcheff @Fede @FiberInternetUser @gadreel @ilovepancakes @impala_84 @intrax @jarugut @juud @kiwiuk @lemon55 @loomes @minigranis @NeoID @Nuno @Piteball @pkdick1 @pro_info @profet @rufik @s2k7 @scoobdriver@setsunakawa @smilenkovski @smileyworld @smoojay @snakefox666 @Snyaify @SpiRe @T-REX-XP @The Chief @toolazy @vasiliy_gr

Synology PSIRT (Product Security Incident Response Team) has recently seen and received reports on an increase in brute-force attacks against Synology devices. Synology's security researchers believe the botnet is primarily driven by a malware family called "StealthWorker." At present, Synology PSIRT has seen no indication of the malware exploiting any software vulnerabilities. More information and security advises: https://www.synology.com/en-global/company/news/article/BruteForce/Synology® Investigates Ongoing Brute-Force Attacks From Botnet

same as https://github.com/RedPill-TTG/redpill-lkm/commit/c390f74e48bbe87ecc7ff898402cd87dc4d62f38#comments

Not sure why I was able to do it but it was some time ago. I suspect it's a legacy boot vs. EFI BIOS configuration (which then implies DS918+ for Jun's loader). In any case, here's a current solution: https://www.virtualizationhowto.com/2019/01/boot-esxi-virtual-machine-from-passthrough-usb/

Thanks, as far i saw still 3.10 kernel source

Now DS3615xs can run DSM7!

Already seen that, we should move to discord or some plain old technology, they are already there

Status Update! Recently we were working hard in the kernel space to bring even more missing things and bring it into a more stable state. That meant we had little time to respond but we're blown away by the number of posts here! mfgBIOS shimming stability As we discussed here before there were moments where some BIOS functions weren't shimmed or there were flaky. This caused the OS to sometimes work correctly but sometimes fail the 24h test. Guess how easy was that to debug and fix However, we did it and now the mfgBIOS shimming should be almost bulletproof! RTC emulation We've added a full RTC proxy layer. This wasn't strictly needed for 3515xs series. However, 918+ and other models use RTC chip which is not natively/fully supported for the Linux kernel. This means that various subsystems rely on mfgBIOS to update the time from RTC on boot. Since that chip does not exist outside of the official hardware we needed to go around that. In short the LKM code plugs into mfgBIOS and serves as a proxy layer between what's a real RTC (or a one from hypervisor) and what mfgBIOS can understand. Currently, the time set/get is implemented. Alarms are mocked to the point that mfgBIOS doesn't complain. In fact the BIOS code can even set these alarms but they will be erased upon reboot. We didn't bother actually writing them to the RTC. The reason being a) we've never seen anybody using it and b) most RTCs [or actually the hw connected to them] is broken to the point that they don't work anyway (or only work from certain sleep states). If the community desires we can add that. Inverting serial ports on 3615xs We hate it. We did it. It's sort of working and it's a big hack. We will most likely disable it by default as this isn't even fully stable. Also this method cannot work on kernel v4 which... well, v7 and 3615xs. Whoever in syno had this brilliant idea should seriously think again before pulling such a stunt again. This breaks a lot of stuff. Fix ttyS0 on 918+ On some platforms first serial port is intentionally disabled. We added a small hack to re-enable it. Virtual Serial Port / UART This is big. In many ways actually. This single commit with over 1300 new lines and the patch taking 70KB was by far the biggest addition. The complexity of this part is really something we grind our teeth on. To make sure the solution works on all kernels without hacks we had to emulate a physical UART chip. So we did. We wrote a whole software-based emulator of National Semiconductors 16550A UART controller, along with support for FIFOs. Additionally, as we wanted the code to perform great we raised the bar and wrote an additional layer of virtual IRQ (as the real ones cannot be used for many reasons here) which actually made the module multithreaded in the kernel. This whole thing took, across all of us, probably close to 150 hours to develop. There were many ideas and failed endeavors. But the full chip emulation should serve us a long way you truly cannot distinguish it from a real thing (as it is not hacking the kernel in any way). If anyone wants to borrow that code for something non-DSM related feel free - it's actually modular and not coupled with the RedPill LKM in any substantial way. Currently, this vUART stuff is not running in the actual LKM. It is meant to be a component to implement PMU emulation. That part requires a two (hopefully) simple functions which react to the data from the DSM and respond like the PMU would. This will also allow us to give a simple hook to anybody who's willing to connect a hardware PMU to get LEDs and what not working ********************************************************************************* v7 testing We're so happy to see the community effort to add v7. As it is now available for 3615xs we will definitelly jump into it and merge PRs if they pass AFTER merging them we will probably reorganize template files a bit as that symlink-hell was a bad idea. Now let us respond to everything: RedPill actually blocks telemetry as well If you want to check that just go the Control Panel and click "What's new" on an update - you will not see a syno page. Currently it SHOULD work on some baremetal configs but it's definitely not tested. It will be plug-and-play when it's stable. We confirmed that ESXi doesn't allow adding virtual USB drives, so we need SATA DOM boot support. Stay tuned. Setting vid/pid or any other options will NOT make the loader work without LKM changes (ok, technically MAYBE if you recreate PCI tree in Proxmox but .... no, that's not the solution and definitelly not for ESXi or baremetal ;)). You didn't provide RedPill LKMs. You need to compile them if you want to play with the current build. You shouldn't try to compile the kernel but the module. Executing make in the kernel dir will try to build the whole kernel (which doesn't make any sense as it will not be usable really). If you're having problems compiling the module the release is not meant for you (yet). We weren't able to access the telegram as they force us to give a valid, physical phone number. For obvious reasons we didn't give them one When we have a moment to arrange that we will arrive for sure. However, as the current stage is still intended for developers (and we're BEGGING normal users to not use it due to missing stuff which causes various trips in the DSM itself). Unless there's some way to use telegram without a phone number which we don't know about? DO NOT USE IT. Seriously, we don't want to sound rude but if we say this is a development release we mean it. The kernel module lacks some functionality required for the DSM to stay stable. In the current state data loss is a possibility. Thanks! We need some smart way for adding kernel extensions outside of the ramdisk (as it's limited in size). Something like Jun's extra.lzma. However, as it uses a different method of loading we cannot simply merge ramdisks automatically hmm... Great job! We love the approach of going docker. We honestly didn't look into the docker toolchain (yet!) you've built but we're excited! What do you think about incorporating it into RedPill-Load repository? We think it will be a great addition so that the whole thing can be run on any dockerized system. Drop us a PM to not pollute the thread. In general it's great - the only thing which we will keep is making sure the user can actually use JSON config and not makefile - we pulled teeth for hours to make it happen in bash as JSON is user-friendly while Makefile... well Onboard network will require a separate kernel extension. This is the same issue as with power button kernel extension - we don't have a good way for not including all extensions in the main ramdisk (which cannot grow too much, especially for 918+). This looks like a broken patch for ramdisk hmm. Is the file even loaded via network? Did you use virtio driver for the ethernet? For any error 13 a full log from /var/log/messages and install_log is needed. However, in general VMWare will not work until we implement SATA DOM as VMWare Workstation/Fusion/ESXi doesn't allow creating virtual USB drives. To add to that EFI boot is problematic in many way as it tries to initialize devices before Linux can touch them. This can end poorly on some hardware when running DSM. That's why we disabled EFI in the GRUB deliberately. You cannot do that. There's no support for SATA DOM in the LKM. This is a known issue: https://github.com/RedPill-TTG/redpill-lkm/issues/3 Telnet access has nothing to do with the loader. It's up to the settings you set in your hypervisor On Proxmox there's a local access through "qm console", on VirtualBox you can set COM1-4 in settings to be a telnet or a raw socket or whatever else. These warning are just really warnings and GCC isn't correct here actually. As 4.8 is old we need some creative way to make it happy. But since this code works as expected and is a weak warning we aren't worried about that. The one regarding unused function is there because we left some skeleton for future shims - that one used to be used before we implemented proper RTC. As for rebuilding kernel: you MUST use the proper GCC for that. It will NOT build with GCC 5.4 properly as v3 only supports up to v4.9 (or something along the lines). Unfortunately Proxmox (or rather QEMU) cannot do a split-brain situation where some instructions are virtualized with hardware KVM acceleration and some are done in software. This means it's not feasible to run emulated haswell when your host CPU doesn't support all the instructions. You CAN do that for testing (disable HW acceleration in VM options) but it's PAINFULLY slow. We use it from time-to-time for testing LKM but it's really like working on a Pentium MMX. That's a good decision in our opinion to move to debian8. It is old... but so is the kernel. We also use Debian 8 VM internally. From what we've heard syno does not use a cross-toolchain for building kernels either. That says something. As for booting on ESXi see above - it will not boot as of now. Isn't unraid using qemu? It should boot no problem (at least to grub) as long as it's a TRUE usb boot and not a sata boot. Can you run the VM and check the output from "ps -a"? Go through it manually and try to find the qemu/kvm process. It will have a VERY long cmdline (like several lines long). This is the ultimate source of truth regarding what's being run. Where precisely does it stop? Can you post a screenshot?

Happy to be helpful. Probably next time you'll spot my obvious mistake 😉 Best, -a-

Synology DSM 6.1 (xpenology) Lets Encrypt ACMEv1 to ACMEv2 If you get messages like: synoscgi_SYNO.Core.Certificate.LetsEncrypt_1_create[5038]: certificate.cpp:957 syno-letsencrypt failed. 200 [new-req, unexpect httpcode] synoscgi_SYNO.Core.Certificate.LetsEncrypt_1_create[5038]: certificate.cpp:1359 Failed to create Let'sEncrypt certificate. [200][new-req, unexpect httpcode] Then you need to upgrade your DSM up to version 6.2 or replace execution (syno-letsencrypt) file and some changes in configuarion file: 1. Download file syno-letsencrypt (this file from DSM v6.2) link https://drive.google.com/drive/folders/1-LgjOAU3dBtNk2WKZ1KJY88Lklf12RPp?usp=sharing 2. If not enabled SSH, please enable in settings 3. Copy downloaded file syno-letsencrypt in any folder on you NAS 4. Connect to NAS with SSH (Putty) using admin account 5. Make backup of original syno-letsencrypt (sudo cp /usr/syno/sbin/syno-letsencrypt usr/syno/sbin/syno-letsencrypt.bck) 6. Copy downloaded syno-letsencrypt file to directory /usr/syno/sbin/ (ex.: sudo cp /volume1/sharedFolder/syno-letsencrypt /usr/syno/sbin/) 7. Change attributes (sudo chmod 755 /usr/syno/sbin/syno-letsencrypt) to execute new file 8. Now change default address for syno-letsencrypt, using ssh (sudo vi /usr/syno/etc.defaults/letsencrypt/letsencrypt.default) 9. Fine string "server": "https://acme-v01.api.letsencrypt.org/directory", press i and change 01 to 02 10. Press escape, enter :wq and reboot your NAS.