Leaderboard

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

Oh boy, have I been sleeping!!!. I got some serious reading to do.

Hello me again, I've got another microserver yesterday and tried to install xpenology on it via Jun loader. Tried 1.02b, 1.04b and 918+ pat and 3617xs pat with no success It worked for the first time but when I upload the pat the nas doesn't get an ip anymore and isn't reachable after that. Tired formatting all drives using Ubuntu livecd and wipefs but now the server doesn't get any ip even before the install.. EDIT: Just tried again with a fresh (newly bought USB Stick) with Loader 1.03b and 3617xs PAT 23739.. Same thing. After upload pat and restart the server is reachable for 1-2 minutes (just shows common:fail) and then nothing again. EDIT 2: Ok works now after changing the BIOS settings to

Ну и по просыпанию...... Советуют посетить БИОС

Скачать можно и на форуме Но эта приблуда, расширяет только функционал Кнопки выключения. К просыпанию Хрени она не имеет никакого отношения

Чтобы работал WOL вроде как нужно зашивать макадреса в сетевые карты. А для кнопки выключения тут есть целая тема.

Oh ! then that looks like a great opportunity for @haydibe to include the module creation on his next redpill_tool_chain release

https://github.com/dogodefi/Synoextradrivers @yanjun has been created extradrivers repo

look at my posts. There should be no problem if it runs in degraded state but you can fix this with maxdisks and internalportcfg/usbportcfg/esataportcfg and then --grow the array with only the maximum hard drives your system supports. This is my config: }, "synoinfo": { "maxdisks": "4", "internalportcfg": "0xf", "usbportcfg": "0x3f0" }, esataportcfg is already 0x0 and I have no esata port. root@Apollo:~# cat /proc/mdstat Personalities : [raid1] md3 : active raid1 sdc3[0] sdd3[1] 971940544 blocks super 1.2 [2/2] [UU] md2 : active raid1 sda3[0] sdb3[1] 483564544 blocks super 1.2 [2/2] [UU] md1 : active raid1 sda2[0] sdd2[3] sdc2[2] sdb2[1] 2097088 blocks [4/4] [UUUU] md0 : active raid1 sda1[0] sdd1[3] sdc1[2] sdb1[1] 2490176 blocks [4/4] [UUUU] unused devices: <none> root@Apollo:~# mdadm --detail /dev/md0 /dev/md0: Version : 0.90 Creation Time : Thu Sep 9 11:12:22 2021 Raid Level : raid1 Array Size : 2490176 (2.37 GiB 2.55 GB) Used Dev Size : 2490176 (2.37 GiB 2.55 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Persistence : Superblock is persistent Update Time : Fri Sep 10 10:57:06 2021 State : clean Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 UUID : cbf9a42e:9fc3aaf1:3017a5a8:c86610be Events : 0.5993 Number Major Minor RaidDevice State 0 8 1 0 active sync /dev/sda1 1 8 17 1 active sync /dev/sdb1 2 8 33 2 active sync /dev/sdc1 3 8 49 3 active sync /dev/sdd1

У меня их накопилось уже под 10 с рабочих НАСов и ни одну я не пробовал на домашнем: мало разве нормальных DDNS-сов?

Не совет , но истина ......👍👍 У меня Три валидные пары и ни одна не прошла