rd.gz

[qwert_wayne]

I'm trying to find out something about the inner workings of the DSM software and how jun's hack works. I extracted the pat file of a 918+ and looking around. There is a rd.gz file, which should be the ramdisk and the tool binwalker says that it is LZMA compressed. However, I cannot unpack the ramdisk neither can I mount it.

 

Can someone tell me how I can open the file?

And while I'm at it: Is there any website or post that explains how the boot process of the filestation works?

 

Thank you for your help!

[IG-88]

On 1/13/2020 at 6:26 PM, qwert_wayne said:

There is a rd.gz file, which should be the ramdisk and the tool binwalker says that it is LZMA compressed. However, I cannot unpack the ramdisk neither can I mount it.

zImage and rd.gz on the loader (2nd partition) are original synology and will be  copied, on updating dsm, to the loader

you can unpack rd.gz using 7zip, let it unpack to folder rd, ignore the error, inside the folder will be the file"rd", let 7zip unpack the same way and you will have the content

start with "linuxrc.syno"

if you want to know about what jun does then you need to start with the loader and look into the extra.lzma

if you are familiar with revers engineering you can take apart modprobe

 

also i'd suggest to read jun's comments, there are some information he gave here an there

 

 

 

 

[qwert_wayne]

Thank you very much! I didn't think of extracting it twice. I suppose there are some uboot files in the first archive. Does anybody know how to extract the remaining part?

I looked into jun's hack and found (as was mentioned somewhere in the forums) that he replaces modprobe. I guess he creates virtual devices to imitate a real synology hardware...? I will try to get to the point where DSM stops working on an unmodified system.

 

[IG-88]

1 hour ago, qwert_wayne said:

I guess he creates virtual devices to imitate a real synology hardware...? I will try to get to the point where DSM stops working on an unmodified system.

yes, you will see such devices with lspci, also synology kernel modules are signed, i dont know if it really active/enforced by synology but we can load modules without a valid signature

 

btw it would be a great help if you could have a look into the synology kernel source so see whats wrong with the actual sas/drivers, it seems our old beta source from over 2 years ago difers to much from what synology uses for 6.2.2 and also for a longer time we cant compile sata drivers

if you are willing to have a look i would collect errors, provide examples and links

also jun made  a backported drm/i915 driver for its 1.04b loader (kernel 4.4.59) to have hardware transcoding support for newer gpu's then kaby lake, but left no documentation and source so i cant recompile the driver for dsm 6.2.2 as i have no coding skills and i did not look like it could be done without that

Edited January 27, 2020 by IG-88