• Content Count

  • Joined

  • Last visited

  • Days Won


kiler129 last won the day on June 16

kiler129 had the most liked content!

Community Reputation

73 Excellent


About kiler129

  • Rank
    Junior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Wait, Intel being evil like with ECC, making a messy implementation and 101 incompatible IDs? I cannot believe it! /s On a serious note thanks for the observation - DS918+ loader seems to have i915 IDs as the first member of the list, but since I didn't look into PCI implementation yet I have no idea if it "by default" loads them regardless of the hardware.
  2. I glanced over it and the project looks great. However I don't think it will be useful here (correct me if I'm wrong, I left the Android hacking space long time ago) as it is very specific to how Android kernel boot process works. Here the issue is Synology added its own ramdisk verification logic. xhci-hcd replaced ehci-hcd - in short xHCI is a unified effort to support all USB versions regardless of their speed from 1.1 to the newest (which got complicated with 4.0 but this is a different can of worms ;)). However it was worth a shot: I tried but it didn't help sadly.
  3. I will say it's more fake-till-you-make-it for me My experience is very limited in this space really. Thank you! That helps immensely! A classical example why different people thinking differently can come up with something great. My whole goal is to actually describe everything and make the knowledge accessible. As of know most of the stuff is not publicly available and seems to be known only by a couple of devs which developed previous loaders. As of now no, I didn't share any repo (except some code snippets to e.g. gen
  4. Good to know, thanks! I didn't follow their DSM 7 release cycle closely as storage is definitely not an area where I like to experiment. Since all my real DSM systems are used for production tasks and I cannot make any configuration changes surprisingly (not even running a VDSM) I was waiting until some stable release is published Thanks! ---------------------------------------------------------------------------------------------------------------------------------------------------------------- There's a liar in the room I had
  5. So, you guys deserve an update like 3 days ago... but I hate doing updates with bad news so I decided to wait until I have good news I think you're mixing two different checksums here. There's a checksum of the PAT when it's uploaded and unpacked (which can be easily defeated) and there's a custom kernel-level checksum. Thanks! I didn't experiment with DSMv7 as, the last time I checked, it wasn't publicly avaialble and only invited people could access an early preview. Franken-DSM is still on the table as this will give us a newer kernel but since
  6. I decided to pursue franken-DSM route - newer VDSM kernel (which supports older CPUs!) with DS3617xs OS. Notable Changes Features only in DS: HA (can be fixed, but does anyone use that with xpenology?) Disk compatibility database (this is most likely easily fixable with manual DB update from settings) Drivers only in DS: igb (various Intel Gigabit ethernets) ip_tunnel ixgbe (Intel 82598/82599 10Gb ethernets) leds-lp3943 mpt2sas (LSI HBA) mpt3sas (LSI HBA)
  7. It is certainly possible to do that. However DSDT is such a painful can of worms that people want to avoid that at all cost. x86 & IBM/PC architecture is a messy ratnest held with a duct tape and 30 or so years of hacks upon hacks. With macOS there are maaanyy things which need to be changed and few hook points (wrt to Linux) - here it's quite the opposite. We have almost the same hardware as the genuine one with just minor differences. In the hackintosh world it's not uncommon to run into Apple using undocumented CPU instructions which are only working properly on their SKUs. In case
  8. Ok, this is gonna be a looooooong post. I spent some time digging around and I'm back. First some responses: To my knowledge the problem is the same as described in the first post - "va not found" (aka the patcher cannot execute the main DSM kernel). It doesn't seem like Synology did anything on purpose, they changed the kernel just enough for the Jun's loader to fail. Synology uses a separate "distro" for VMM. But why do we even need a kexec? VMM boots the kernel directly and just insmod couple of other modules for serial and virtio stuff.
  9. IMHO it is not relevant where they check things but how they do that. Patching checks can get you only so far, it's a better approach to emulate responses. I don't think Syno nor Apple are interested in deliberately trying to block unauthorized installs and only REALLY protect access to their services ($$$, security). With a slight OT I can say Syno got six-figures in hardware because I was able to poke around with Xpenology privately to later recommend it for business deployments. I'm sure they're fully aware of that - nobody in a right mind would use Xpenology commercially (legal issues asid
  10. Ok, that will sound stupid but is that script built into the DSM itself or something the loader does? Normally when I see kernels there's a separate kernel image + a ramdisk to fiddle with. The bzImage supplied with Jun's loader seems to only have the kernel image (but Jun wrote that there IS a ramdisk)... the only separate initrd I see is the Synology's one. Is there any place with dev resources? I have some experience with kernel hacking (e.g. and low-level patching for hackintosh but my knowledge of Xpenology is limited.
  11. Yeah, I'm aware it is much more complex but this gives a glimpse of what the process was. I saw there were some (successful?) userland attempts too. I'm trying to piece-out what is his module doing/what it has to do without jumping to IDA. In other words what "security" did Syno put into place (or rather what they check because if they wanted to block it they would put a proper security layer). So far I see two big areas: - Synobios emulation - Making sure our USB drive is seen as /dev/synoboot I tried this but I got nowhere as the kernel stop
  12. Did Jun or anyone else ever published the patches? I found with scripts he used as well as the general description of his efforts: However I cannot find anything more.
  13. After seeing a sea of report for 6.2.4-25554 and 6.2.4-25556 I fired up my test rig and got the same result as for for v7 release: va not found Failed to process header This seems to happen way before the kernel is actually loaded into memory. I compared before & after boot images and not surprisingly the kernel did change. From my limited knowledge of Linux boot process I started poking around and even binwalk doesn't recognize the new image: Scan Time: 2021-05-30 13:01:52 Target File: /mnt/_synoboot-old/zImage MD5 Checksum: e3d859f75819dda05e065c5da
  14. - Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 6.2.3-25426 Update 3 (clean install) - Loader version and model: JUN'S LOADER v1.03b - DS3615xs - Using custom extra.lzma: Yes (virtio) - Installation type: KVM (Proxmox) - Additional comments: reboots and stalls before booting Linux with the following on serial: va not found Failed to process header
  15. - Outcome of the update: UNSUCCESSFUL - DSM version prior update: DSM 6.2.3-25426 Update 3 (clean install) - Loader version and model: JUN'S LOADER v1.03b - DS3615xs - Using custom extra.lzma: Yes (virtio) - Installation type: KVM (Proxmox) - Additional comments: reboots and stalls before booting Linux with the following on serial: va not found Failed to process header