Reverse engineering Synology’s NoteStation for blog system

My Blogging Journey

• Infrastructure needs to be stable and reliable
• The blog system needs to be fully controllable
• Writing needs to be convenient

• Excellent multi-platform support (especially for Linux and Android platforms)
• Has a Chrome plugin similar to Evernote (this plugin can be used to quickly save web pages, it’s simply a re-posting artifact)
• Private cloud (infrastructure is fully controllable)

Encoding Problem

Solution to the Encoding Problem

Through the directory, we can basically guess that the files under webapi may be mainly used to provide interaction with the user’s web page, and the files under lib directory mainly provide support for various basic functions.

But this is of no use - we need to know how to decode the mysterious encoding mentioned in the above text.

Actually, it’s not without a clue, at least we know that the program needs to process the files in the version/text directory, in other words version/text is our breakthrough.

Since Synology’s system lacks many basic commands, I packed the files and dragged them down together, the packing command is as in the last line of the above picture:

1. find ./ -type f -iname '*\.so*' -exec cp {} /volume1/Documents/Sos \;  

Then use the following command to extract all visible strings from the so file, and filter out the strings containing text/:

1. strings -f * | grep -Pi 'text/'  

The result is as follows:

Luckily, there are not many files. And the webapi and lib directories mentioned above are actually a bit useful, basically we only need to look at the libsynodrive.so.6.0 file, the other few files are actually related to HTTP text (and these few files are all in the webapi directory).

Take out the omnipotent IDA, shift+f12 to extract strings, locate to /text/* place:

There are two references, after observation, the reference at sub_583a0+9C is not what we need, now there is only one left, it’s simply awesome. Navigate to this call place, find that it is an assignment to pattern (line 171 in the picture below):

Then track the cross-reference of pattern and find that line 303 in the picture above is the key position, because v107 assigns to v129 through std::string::assign, and the SYNODriveDecode function at line 306 references the v129 variable, the SYNODriveDecode function looks like it can answer how we decrypt the mysterious encoding:

1. __int64 __fastcall SYNODriveDecode(const std::string *a1, unsigned __int8 *a2, size_t a3, char a4)  
2. {  
3.   // [COLLAPSED LOCAL DECLARATIONS. PRESS KEYPAD CTRL-"+" TO EXPAND]  
4.   
5.   v4 = *(const char **)a1;  
6.   v5 = std::string::_Rep::_S_empty_rep_storage;  
7.   n[0] = a3;  
8.   v6 = *((_QWORD *)v4 - 3);  
9.   v27[0] = (__int64)off_2E7F50 + 24;  
10.   if ( !v6 )  
11.   {  
12.     //  Omit error handling code
13.     ……  
14. LABEL_3:  
15.     ……  
16.     goto LABEL_4;  
17.   }  
18.   if ( a4 )  
19.   {  
20.     std::string::assign((std::string *)v27, a1);  
21.     v11 = 0LL;  
22. LABEL_8:  
23.     bzero(a2, n[0]);  
24.     // SLIBCBase64Decode is a function packaged by DSM. It is guessed that it packages the base64 decoding function.
25.     if ( (unsigned int)SLIBCBase64Decode(v27[0], *(_QWORD *)(v27[0] - 24), a2, n) )  
26.     {  
27.       v8 = 1;  
28.     }  
29.     else  
30.     {  
31.       // Omit error handling code
32.       ……  
33.       v8 = 0;  
34.     }  
35.   }  
36.   else  
37.   {  
38.     v11 = (char *)calloc(v6 + 1, 1uLL);  
39.     if ( !v11 )  
40.     {  
41.       // Omit error handling code
42.       ……  
43.       goto LABEL_3;  
44.     }  
45.     snprintf(v11, v6 + 1, "%s", v4);  
46.     v22 = &v25;  
47.     while ( 1 )  
48.     {  
49.       v13 = strchr(v11, '{');  
50.       v14 = v13;  
51.       // If there is not character '{' exists  
52.       if ( !v13 )  
53.       {  
54.         v21 = strlen(v11);  
55.         std::string::append((std::string *)v27, v11, v21);  
56.         goto LABEL_8;  
57.       }  
58.       *v13 = 0;  
59.       v15 = strlen(v11);  
60.       std::string::append((std::string *)v27, v11, v15);  
61.       *v14 = '{';  
62.       v16 = strchr(v14, '}');  
63.       // No more characters which is {xx} format
64.       if ( !v16 )  
65.         break;  
66.       *v16 = 0;  
67.       v11 = v16 + 1;  
68.       v17 = strtol(v14 + 1, 0LL, 10);  
69.       *(v11 - 1) = '}';  
70.       std::string::string(v28, 1LL, (unsigned int)v17, &v25);  
71.       // Convert xx in {xx} to decimal using strtol
72.       // The append the summoned integer as a character to then end of the string to be processed  
73.       std::string::append((std::string *)v27, (const std::string *)v28);  
74.       v18 = v28[0] - 24;  
75.       if ( (void *)(v28[0] - 24) != v5 )  
76.       {  
77.         // Omit error handling code
78.         ……  
79.       }  
80.       if ( !v11 )  
81.         goto LABEL_8;  
82.     }  
83.     syslog(3, "%s:%d Failed [%s], err=%m\n", "common/synodrive_common.cpp", 839LL, "NULL == szEnd");  
84.     SYNODriveErrAppendEx("common/synodrive_common.cpp", 839, "NULL == szEnd", (char)&v25);  
85.     v8 = 0;  
86.   }  
87. LABEL_4:  
88.   free(v11);  
89.   // Omit error handling code
90.   ……  
91.   return v8;  
92. }  

Okay, the logic is basically clear: extract the string in {}, then convert it to the corresponding decimal number, finally replace the ASCII value of the decimal number as a character to the original position in the original text, and finally decode with the private function SLIBCBase64Decode.

About the SLIBCBase64Decode private function, I’m too lazy to find where it’s implemented, for now, just close my eyes and assume it’s the Base64Decode function (having a signature is awesome: Synology-LIBC-Base64Decode).

It’s still a bit abstract, take version/text/Y{110}J{112}ZWY{61} as an example:

1. ASCII(110) -> n  
2. ASCII(112) -> p  
3. ASCII(61)  -> =  

So version/text/Y{110}J{112}ZWY{61} is converted to: version/text/YnJpZWY=

Now it’s much more pleasing to the eye, everyone on earth knows that YnJpZWY= is base64:

It turns out to be the meaning of the introduction~

Coding Time

After the verification is okay, the next step is the simplest part.

From the above analysis, it is easy to get the code used for decoding (Typescript syntax):

1. const bs_filenameDecode = (filename : string) : string => {  
2.     let decoded_filename = '', current_position = 0;  
3.     while (true) {  
4.         const curly_start_position = filename.indexOf('{', current_position);  
5.         if (curly_start_position != -1) {  
6.             const curly_end_position = filename.indexOf('}', curly_start_position);  
7.             decoded_filename += filename.substring(current_position, curly_start_position);  
8.             decoded_filename += String.fromCharCode(  
9.                 parseInt(filename.substring(curly_start_position + 1, curly_end_position))  
10.             );  
11.             if (curly_end_position + 1 === filename.length) break;  
12.             current_position = curly_end_position + 1;  
13.         }  
14.     }  
15.     return decoded_filename;  
16. }  

As for why the author of NoteStation would use such a strange encoding method, I can’t guess. But the libsynodrive.so.6.0 file also exposes a function called SYNODriveEncode, this function is used to encode a “mysterious encoding”, here I won’t post the IDA HexRay code of this function, just say the result: the function encodes the input string with base64, then converts all characters outside [A-Z0-9] into {corresponding ascii value} format.

The corresponding encoding logic is as follows (Typescript syntax):

1. const bs_filenameEncode = (filename : string) : string => Buffer.from(filename)  
2.     .toString('base64')  
3.     .split('')  
4.     .map(
5.         c => /[A-Z0-9]/.test(c) ? c : `{${c.charCodeAt(0)}}`  
6.     ).join('');  

With bs_filenameDecode and bs_filenameEncode, you can happily read the introduction, main content and other data of various notes in NoteStation.

Postscript

Actually, the entire blog system has been completed, it’s just that because I am a late-stage lazy cancer patient, I only started to write something now.

In the engineering process of the entire blog, there are actually many security issues involved - you guys don’t think the backend is running directly on Synology’s NAS, right? Don’t think that the entire system is not isolated, right? Don’t think that any note can be viewed through the blog system, right? These related issues, if there is a chance, I will write something specifically to share with you.

Finally, here is a screenshot of the blog backend which I want to show off a little bit ;)

Reference

1. Record of various recovery methods for NoteStation log data corruption in Synology system