Hello, everyone.
The next speaker is Kevin.
Kevin is a member of the Boston CTF team.
He has won the third place many times in DEFCON and HECON.
He has also repaid many serious loopholes.
He is now a P-Cert in Synology.
Today, he will introduce to you the actual details of the unit management system, the Outflow of Band Management System.
How is Synology made?
And how does it bypass the protection mechanism of the system from a distance to directly obtain the highest authority of Synology NAS?
Let's welcome him with a round of applause.
Thank you for the introduction.
Hello, everyone.
Welcome to today's session, Reaching Beyond Boundary, Out-of-Boundary Exploration in Out-of-Band Management.
I am Kevin.
As for the introduction, the host has already introduced us.
He will introduce us in detail.
Let's get started.
First of all, today's outline.
We will first introduce today's target.
Next, we will analyze its attack surface.
Then, we will explain the loophole we found.
Finally, how to fix it and the conclusion.
First of all, let me introduce.
This is our target today.
It is a Synology NAS machine.
Its characteristic is that there is an independent port at the back of the network port.
It is the so-called Out-of-Band Port.
Its function is that it will be built on different channels.
And when it is executed, it is an isolated environment.
When your NAS is attacked, it can be managed from there.
That is our target today.
If you look closely at its functionality, it is actually like this.
You can go to SSH, enter your own IP and your own port.
When you go in, I just said that it is an isolated environment.
In other words, it is not a NAS processor and then open a port to listen.
Instead, it has its own processor and its own memory.
It is an independent small system operating on the network port.
If you go into SSH, you can see the above functions.
Those functions are obvious.
It is not what we usually know.
Linux, SSH, bash or shell.
It is a custom shell written by itself.
At the same time, if you look at the functions inside, it is the purpose of some managers.
For example, you can turn off your NAS or you can monitor the system log.
If you analyze it, you will find that its firmware is a MIP32B architecture.
At the same time, its structure will be the self-defined firmware structure of Realtek.
It is not a common firmware structure.
If you look at its behavior, it can serve multiple SSH connections at the same time.
And as I mentioned before, after SSH goes in, it is a custom shell.
When you see the custom shell, you will think that it is worth seeing.
Because it should do a lot of command parsing by itself.
Since there is command parsing, it should be the easiest place to show up.
In fact, that's right.
When we look at the command parsing part, there is a very simple Stack Overflow.
At the time of Power On and Power Off, you can write Power AAA directly.
When Power AAA goes down, you can see the code below.
No matter which branch it goes to, it will put the ARGv2, which is the AAA we gave, to the Sprintf buffer.
The buffer will be a region variable, which means that we will have a Stack Overflow here.
After the Stack Overflow, I believe that if you are playing CTF or have attack experience, you will think that this is quite simple.
We can get the command system running, and then there is a Post-Auth-RC.
In this case, if we have Post-Auth-RC, as long as we have a loop on the authentication, this can be connected to Post-Auth-RC.
Then it feels very easy, very simple.
But in fact, if we actually try to play Power AAA, we will find that it has no response.
It doesn't have any crash, or even the function doesn't jump.
And if we go back and check the code, we will find that this is too naive.
In fact, in the earlier part, it has dropped all the commands that are greater than 2.
That is, it is very cruel, only letting you enter 0 to 9.
The menu just has a menu, and then you can directly enter 1, 2, 3, 4, 5, 6, 7, 8, 9 like this.
It only handles that kind of request.
It won't deal with any of your input, such as power on or off.
Seeing this makes me very angry.
After all, you just wrote a hole in the back.
You wrote the hole yourself, but you don't dare to use it.
What the hell is going on?
And then you block it in the front, and you can only handle 0 to 9, right?
And then you say, what the hell are you afraid of?
Come out and face it.
You wrote the hole yourself, face it.
But even so, even though it is blocked, you can only touch your nose and tell it, although it is shameful, it is useful.
You block it, it is really blocked.
Of course, this can't be said to be a bad thing.
After all, if you break through like this, today's talk is only five minutes long.
It's over now, right?
In fact, because it is blocked here, so we have to dig in other directions.
If you analyze it further, you will find that its division is actually changed from microcosm.
As I said before, it is not like the show we usually get into.
In addition, its binary, the binary of its division package, is actually obj.copy-obinary.
Then it is its own format.
It is used by itself.
So even if you want to reverse it, it will be quite difficult to reverse.
There is no way to understand its format directly.
The worst thing is that we didn't debug this thing.
Because as I said, this is not a Linux system.
We can't just SSH into GDB, attach to some process, then we know all its memory layout, or all the details, etc.
We don't know.
At the same time, there is some protection.
We can usually checkseq directly, to see if there is canary, ASL, etc.
These are all unknowns.
It looks a bit difficult here.
But let's go back to the very first idea.
Take a step back and think about it.
In the beginning, what is the exploration in our dream?
If we find an authentication bug, then we can log in.
After logging in, plus the stackoverflow of postall, we can achieve a BIOS RCE.
This is a wonderful fantasy.
Although postall stackoverflow has been proven, it is actually unbreakable.
But if you look at this carefully, you will find that you still need a pre-auth vulnerability.
Since we are in stackoverflow, and how to use it later, let's take a look first.
What can we do in pre-auth?
To look at pre-auth, we need to look at SSH protocol.
The only attack here is SSH.
After all, it is its own independent system.
The only function it has is SSH.
When analyzing SSH, I also found one thing.
It is actually changed by dropping SSH.
Then there will be a question here.
Before SSH authentication, what can we do?
In general, this is my original understanding.
I may think that you just enter the account password.
Or there is public key authentication.
Maybe there are only these two ways to log in.
It seems that nothing else can be done.
And here, public key authentication is disabled.
It means that it does not support public key on this system.
It also means that when you are in pre-auth, you can only enter the account password.
Then the attack seems to be only SSH user's IP left.
Then go in there, and password, just give it a, and give it 10,000 a, and see if it has a crash.
Crash means there is a hole.
If there is no crash, then thank you for contacting.
It sounds like a little stupid.
In fact, if we analyze the SSH protocol carefully, we will find that SSH actually has different messages.
Then different message types have their own numbers.
If you see the if section of the code, it is actually judging that before you finish the auth in SSH, if the message type you give is greater than the max on auth type, then it will go directly to exit.
This sentence, on the other hand, means that before you on auth, if your type is less than this define, then you can do the operation.
Then if we go after this define, we will find that it is defined as 60.
That is to say, we seem to be able to enter the account password from the original, and there may be 60 operations that can be used.
It seems to be quite a big attack surface.
In fact, if you look at the message define, you will find that it is all the way from 1 to 100.
But in fact, not every number is defined.
It's quite inconsistent.
It will jump.
In fact, if you look at the SSH message that is less than 60, it's probably the green boxes.
There are more than ten of them.
To be honest, there are not very many.
But it's better than only entering the account password from the beginning.
After all, there is a little more attack surface.
In this way, we also have a direction to attack in this direction.
Next, after the concept of SSH protocol, let's talk about the loopholes we found in it.
First of all, the first one is the loophole found in the SSH process.
The reason is that after the SSH key change, your cipher mode will be set up.
It's usually AES-128 or 256.
Then, all your packages will be encrypted.
This should be the same as everyone imagines.
In this case, when it is converted into a code, it will determine where the green box is.
Your cipher mode, if this is not NUM, it will decrypt your package.
After decrypting, let's take a closer look at the deadlock in the decrypt package.
We will find that the format of SSH is actually quite simple.
It will give a LAN1 at the beginning, and then a message1 with a length of LAN1, and then a message2 with a length of LAN2, and so on.
It's actually a pretty simple format.
Then, from here, you can see the decryption steps.
What it does is the first two lines above, it will decrypt the first block, which is the first 16 bytes.
After decrypting, it will take out your first LAN1.
It is the whole packet length.
Then, you will see if your packet length is greater than the block size, that is, if it is greater than 16, it means that there are still things behind you that have not been decrypted.
Then, you will decrypt all the things behind.
Then, the decrypted things will be placed on the buff.
Then, the buff is a buffer that is made log and the size is 1500.
Then, here, you may feel that the first packet length is controllable.
That is to say, if we only send 1500, it seems that it can cause a heap overflow here , and then directly overflow the buff.
In this case, it seems that there is no problem.
This is the first hole.
But, to be honest, it seems strange.
After all, 1500, to be honest, is not a very large value.
Generally, users may not use 1500 A.
Few people will do this.
But, when we SSH protocol, or key exchange, those keys, or those numbers, RSA, DFA, those feel very easy to exceed 1500.
Then, it will not trigger a heap overflow in normal use .
In fact, if we really try to put that SSH, whether it is in the password, directly input 2000 A, or after logging in, input 2000 A there, we will find that your heap overflow will not be triggered at all.
What does this mean?
Does it mean that the hole we just found is a fake hole, false positive.
In fact, it has no heap overflow at all.
No .
After careful research, we found that the reason is actually because when the SSH message channel opens, its SSH server and SSH client will agree on, that is, they will agree on a remote mesh packet.
Then, after having this remote mesh packet, the next server and client, the two packets will not exceed this value.
You can see from the code here , that is, if it judges that your length is greater than the remote mesh packet, it will directly turn length into equal to the remote mesh packet.
Then, it will only send a remote mesh packet of this length out.
Then, the rest will be left for the next time.
So, this is true.
If you use a normal OpenSSH or DropBeer SSH client to connect directly, no matter how hard you hit tens of thousands of A, it will eventually be cut into several 1,500.
Because they had already agreed that your buffer cannot exceed this size.
So, you can develop exploits or make changes to the client's source code to violate this premise to make this heap overflow.
Since we are sure that there a heap overflow , we need
to create
a memory buffer make we sure that we can make sure that we can that make sure Next is chunk 0x10, then a bunch of 0x10 all the way down.
The biggest is to chunk 0x100.
After cutting these chunks, how does it manage these free chunks?
It's actually very simple.
It's a single list structure.
According to different sizes, it will be on different lists.
For example, for size 8, it will be under the link list of size 8.
For size 10, it will be under the link list of size 10.
When you call matlock, what does it do?
It finds the first chunk bigger than your request size, and takes it out.
If all the chunks are used up, it will print an error.
For free, it will return the PTR value to the corresponding chunk.
The link list here will be a stack structure, which is your first int or last out.
For free, it's a little different from glibc.
If you use linux, you may know that glibc has a header in front of its heap to store how many chunks it has.
Here it doesn't.
Here, you can see that it has determined that your chunk size 0x8 must start at a certain address, and there are a few chunks fixed at the end.
So the beginning and end of chunk 8 can be calculated.
The same for chunk 0x10, the beginning and end can also be calculated.
So in free, it directly checks which section your memory should be in, and it will put it back in your corresponding linux section.
The whole structure is very simple, and the best part is that it's very similar to glibc's tket, and it doesn't have any check.
We did some double-free checks on tket, and nothing was done here.
It's just a bare tket feeling.
Now that we know that it's very similar to tket, we can use the tket method to attack.
Let's say there are four A, B, C, D memory, and my B is in use.
At the same time, my B can...
because we just had heap overflow, so our B can do heap overflow.
How do I attack at this time?
I'll overflow from B, and overflow will write to C.
After writing to C, because the FD of C, which is the next place next to C, is covered by us, which means that the FD of C is D, and it's heaped overflowed by us.
We can write to any place we want, and the structure of the linked list will look like this.
And when it becomes A pointing to C pointing to anywhere, suppose we go to malloc 0x1003 times at this time, the first time will get A, the second time will get C, and the third time will get any place we want.
In this way, we can get arbitrary memory write.
Looking back at the use of decrypt packet, we said that the buff size is 1500, and it corresponds to 0x5TC, which means it corresponds to 0xchunk 0x600.
So if we can malloc 0x6003 times, we can use heap overflow, and use tk.poisoning to get arbitrary write.
It's like this.
But there's one thing to note here, which is why we can only malloc chunk 0x6003 times.
It's because of the same structure as before.
Because in the 0x600 section of Microsoft EOS, everything around it must be 0x600 chunk.
Unless you use 0x600 chunk to the point where it's almost gone, and get the last few lines, then you overflow it, then it might be chunk 0x800.
But in our general use case, and we don't have a memory leak hole here, so basically our 0x600 heap overflow can only overflow 0x600 chunk.
We can't overflow other sizes.
So this will cause you to say, you can only malloc 0x6003 times to trigger it.
But there's another problem here.
If I flip the entire ss message of less than 60, you'll find that there's no place to malloc 0x6003 times.
And the closest place is when you log in.
When you log in, you can see this code.
It will get your sdr.len.
And see if your sdr.len is less than maxString.len.
And maxString.len is 512.
Which means your sdr.len is 511 at most.
And then it will malloc sdr.len plus 1.
Which means you'll malloc 512.
And 512 to hex is 0x200.
Which means you'll get 0x200 at most three times.
And this is very, very close.
Because as long as it's 0x201 over 0x200, the next chunk will be 0x600.
But in fact, it's very tragic.
We don't have 0x600 here.
And here, it's kind of like a CTF heap problem, right?
After all, we all watched Angel Boy grow up.
Angel Boy arranged a bunch of heaps over there, and came up with a bunch of weird tricks.
When faced with this kind of problem, it should be solved by arranging heaps, right?
I didn't expect Angel Boy to say this.
Wow, how could it be like this?
He was the one who arranged the most heaps, but now he says it's a waste of time, and it's better to find a new hole.
This is a big blow.
But to be honest, after all, this is the realm of the gods.
Like us mortals, we still have to face a problem.
I can't find it.
I just can't find any other holes.
I can find it up and down.
It's this heap overflow.
What should I do?
I can't do anything about it.
Should I just take it as a crash and compromise, right?
So I can't help it.
I can only go back and arrange heaps.
If you want to arrange heaps, as we just said, the premise is that we have chunk 0x60 overflow.
It needs to use malloc 0x6003 to trigger.
Can we turn this situation around?
Turn it into chunk 0x600 overflow, and then we can use malloc 0x2003 to trigger.
If we can arrange heaps to some strange state, and then we can trigger like this, then this problem should be able to reach arbitrary right.
Here we are going to try this thing.
First of all, the first one is the same.
We just have A, B, C, D, and then B is being used, and then it can be overflowed.
At this time, we go to overflow B, we should say that we use B's heap overflow to overflow to C's FD.
At this time, we don't point C's FD directly to any place we want to point, but point to the middle of E.
Then E is a free chunk of size 0x200, like this, pointing to the middle of it.
Then what does it mean to point back to the E prompt?
Because it said in the front, when we are logging in, we can actually go to allocate 0x2003.
So in the front, we can actually do a fake login, and then let E be free.
After that, the content has an outflow value, and then that outflow value points to our D.
This is the first setup.
After this setup, what we are going to do is to establish the second connection.
At this time, to establish the second connection, its A, C, E prompt, and E will be taken out as 0x600 chunk.
At the same time, E will be taken out as 0x200 chunk.
These buffers are taken out to deal with some socket sessions, or what your cipher needs to use.
What to do is actually not very important.
We just need to take it out.
The next thing to do is to do nothing, and then disconnect the second connection.
What will happen after disconnecting?
The A, C, E prompt D we just took out will be freed back, and E will be freed back at the same time.
But the heap here seems to be different from the state we were in at the beginning.
Because the state we were in at the beginning was A pointing to C, pointing to E prompt, pointing to D.
Now it seems to be E prompt running to the right.
Isn't it in 0x600 chunk?
This is actually using the micro-COS free feature.
Because when it's free, it will actually go straight to see which chunk belongs to which part of your memory.
Can you figure out which chunk belongs to which part?
Because E prompt is in the middle of E, so if it calculates, it will definitely find that it is in the area of 0x200.
So when it is freed, it will be freed in.
So after this operation, we will have an E pointing to E prompt in the size of 0x200, and a structure pointing to F, G, G.
Then we just need to establish the third connection.
The third connection, because when logging in, the 0x200 chunk will be allocated three times, and the content is controllable by us.
So for the first time, we will get E out.
And when we get E out, because the content of E itself can be written by us, so it can definitely write the FD of E prompt.
Because E prompt is the chunk in the middle of E.
Then if we write E prompt, we can write E prompt to any place we want to write.
Then, in the second time of Mailog, we will get our E prompt.
Then in the third time of Mailog, we will get any place we want to write, and then we will reach arbitrary write.
So in this case, we successfully turned Heap of Work into arbitrary write.
Then in a further experiment, we found that the whole system does not have ASOR, and it does not have NX.
So we can write stack directly, and return directly to the show code.
In this case, we have reached a remote arbitrary code execution.
But here, to reach remote arbitrary code execution, there is a small problem.
It was mentioned earlier that the branch position was changed from microcosm OS.
It did not show.
Then it means that you can not directly system, and then a command becomes a very powerful command or something.
Then the last second, it is a more important point.
It is actually in an ISO environment.
In other words, we now have a code execution.
But where is the code execution?
It is actually in the NAS network port.
Then the network port has its own process and memory.
We call execution on the network port.
In fact, we can not touch the NAS itself.
It can not read the information inside or something.
It seems that you got a jump board.
Then maybe the jump board can do something.
I'm not sure.
Then here, we have to find a way to change the code.
Do we have a way to further affect the NAS?
Then, when I was studying the function of OOB, I found that OOB actually has the function of resetting the NAS.
Then when the mode 2 is reset, its feature will actually save all the data, and then reinstall.
Then because you have reinstalled, so you can re-enter your manager's account password.
Then you can get a complete admin privilege on your NAS.
Then there is a feature used here, that is, in normal circumstances, can your manager log into OOB and achieve this?
In fact, it is not possible.
Because your manager can log into OOB, although he can reset the NAS, but when resetting the NAS, the network of the NAS will actually be cut off.
It can only be touched on the internal network.
It has no external network.
So at this time, you have to be there, you have to be on the internet, in order to reset the manager's account password.
But here is a feature used, that is, we are actually in OOB, there is co-execution in that little network.
That is to say, when I am here, send a request to the NAS, the NAS will think I am on the internet.
That is to say, I can smoothly, from the co-execution here, to reset the NAS, and then from here, send a new account password to the NAS.
Then you can set the NAS, we want the account password, get full and min privilege.
Then, in this way, you will get a full change scope loophole.
The second loophole is to talk about when allocating session.
When allocating session, there is a thing called session pool.
Then it is a global variable.
Then it will also store, some SSS session structure, and so on.
And then, I said before, that OOB can actually support, that is to say, it actually looks inside, it has two threads, processing the session request.
That is to say, if you have two people, at the same time, to ask for this session, then there is no lock here.
That is to say, you may have two people, will raise to the same session.
Then raise to the same session, what can we do here?
Let's think about it.
That is to say, we just raise, a session that the administrator is just logging in.
That seems to be, the result that can be caused is, we normally log in to OOB.
But in this situation, to be honest, if you think about it carefully, you will find it very impractical.
Because it is equivalent to saying, you have to be crazy over there, poke it to raise condition, and then the administrator, at that time, log in, and then you have to, at the moment when it successfully logged in, just poke it, its LOK, that is to say,
raise it.
This probability, however you think, is quite low.
That is, after all, it is impossible.
In fact, I tried to poke it with my hand, I have never succeeded.
But even if it really succeeds, it doesn't seem to be very serious here.
It's just a pretty ordinary, and then there is no very interesting loophole.
But there is another question here, that is, do we have a way to make this loophole, become more serious?
Suppose we raise our own session, what will happen?
The first point is, because the time of two sessions, is controlled by us.
So it becomes, we can increase the success rate, very much.
Then, the second point is that, you raise to two, the same session, although you failed to log in, that is, it did not successfully log in.
But after all, it will take some, session structure, it will allocate some buffers.
Then we go to see, what will happen, when its session is closed.
That is, it actually, will go to, common session code, the code here, it will go to see, if those buffers, if there is a value, it will just free it.
Then pay attention, after it is free, there is no return.
It means that, you raise two sessions, when you raise to the same, buffer , two sessions, just disconnect, brainlessly .
Then, here, it will be, double free.
Then, we have, the second loop, that is, a risk condition, causing double free.
Then, what can double free do?
Back to, TK's attack, because we say, hey, the heap here, is like TK.
Then, what is to be done here, is TK dupe attack.
Its usage situation, is like this, suppose, now there is, BCD is free, and A is in use.
Then, suppose, we free A, what will happen?
It will be thrown into, the thing list.
Then, if there is, double free, we free A again, what will happen?
Then, this will cause, A's point, it was pointing to B, it will become, it points to itself.
Then, this will become, a strange structure.
Then, what do we do next?
We go to, Malloc three times.
The first time, we will take A out.
Then, when we take A out, we can write, A's content.
So, A's FD must be, controllable.
So, A can be, pointed to, any place we want.
Then, the second time, Malloc, we will get A again.
But this time, A is not important, we don't do anything.
The point is, the third time, Malloc, we can get, any address we want.
Then, here again, arbitrary write.
So, here, we use, that, I should say, the later use, is actually the same.
When we have arbitrary write, it's the same as before.
In fact, you just write, stack return to show code.
Then, use show code, to reset NAS.
Then, at the same time, send your, new user account password.
You can, have another, unmeaned RC.
So, here, we put, a, actually, hit probability, hit luck.
And, just right, unmeaned login.
Then, after login, it seems you only have, autoban, the full line.
Directly turn it into, a, you don't have to hit luck.
To be honest, you still have to raise.
But, the success rate of raise, is quite high.
Then, and can reach, full RC, like this.
Then, here, I don't know if everyone has a question, that is, a, is it so smooth?
That is, after all, the method just before, is, you session, took a lot of buffer, then it should be, a complex structure.
At this time, you are brainless, actually double free it all.
Then, after double free, you are there again, took a lot of memory, to do the following things.
There really won't be, segmentation fault, or something like that?
The answer is, no.
Because here, there is a, micro-COS, has a very good feature, that is, when you dereference, an invalid address, it will actually spray, 0xdebit to you.
Here, super cool, that is, when I was, developing exploits, I was thinking, why is there a, debit on my screen, I didn't, I didn't input this value, did I get hacked?
Then, I found out, it is actually, as long as you dereference, invalid address, it will give you debit.
And even more, when you, continue to, dereference, debit, it will become, 0xdebit.
So here, it will become, a very cool structure.
An invalid address, dereference, becomes debit.
Then dereference, becomes 0xdebit.
Then dereference, becomes, because it is, 0xinvalid address, so it will become, debit.
Then you can loop, indefinitely.
You can, indefinitely dereference, it won't, segmentation fault, it can, execute well.
Then, even, even, even cooler, is that, these memories, are all writable.
For example, today, you dereference, a, invalid address, it is debit.
Then you say, ok, now I want to set, 0x1234, you will succeed.
Then next time, you dereference, 0xdebit, it is 0x1234 again.
Then if you, continue dereference, 0x1234, it is invalid address, so it will become, debit again.
So it is a, no matter how you write, how you read, it won't crash, a very, cool architecture.
And this, is really, the best feature ever.
Strongly recommend, Windows, Linux, and Mac, all need to, implement this feature.
You, in the future, will never, use segmentation port.
Ok, after this, let's see, how to use, mitigation.
In fact, this loop, affects only three, three, OOV port, and then, as long as, it is updated to, 7.1.1, above this version, this loop, can be fixed.
Ok, finally, conclusion.
Then, here, we have, introduced a, for specific, NAS, new, cache service.
And, this concept, is new to me, when you, are playing, IoT device, or something else, except, the system itself, the external port, you go to, NASDAQ, to see those ports, you can also see, does it have any, external hardware, external common hardware,
you can touch, and even, those hardware, drivers, can also, attack.
Then, the second is, that, firmware, although, it is, difficult to , analyze , that is, after , this loophole, actually, a large part of the time, is to, organize this, because at the beginning, there is no direction, instead, the loophole, is not, very complicated.
But, once you, analyze this, and find the loophole, its reward, is actually, quite high.
The reason is, because, these, more , lightweight, processes, or, lightweight, they, in order to pursue efficiency, or something, actually, its security protection, may not be very good.
In this case, it, you see, it has no ASL, no NHD, no Canary.
I have an overflow, I can write anywhere, that is, anything I want, no need to do any leak.
Then, the last one is, Microsoft OS, the best OS.
OK, thank you all.
OK, thank you very much, Kevin, for such a wonderful sharing.
Analyzing a, more special, attack of NAS.
Then, we still have, five minutes, right?
Then, we open three questions.
Please, if you have questions, raise your hand.
No questions?
OK, if no questions, let me, on behalf of, Kevin, ask a question.
How did you discover, this , attack service, is different from others?
Oh, this point, actually, someone told me.
It's, because I'm actually, working at Snowy, and, attacking our target.
Then, there was a, manager, he took a look, and thought, hey, this place, can be attacked.
Why don't you attack it yourself?
Then, I did.
Oh, OK.
Then, it's someone else's, attack service.
Yes, yes , yes, yes, yes, yes, yes , OK, press it, no problem.
Hello, this, this product, it's, the HIP mechanism, is quite special.
It's a HIP, with a self -dryer .
I want to ask, this kind of self-dry HIP, is it common?
Then, why is it doing this?
What's the benefit?
Actually, I'm not sure, whether it's common or not.
But, truth be told, it's not self-dry, it's Microsoft OS.
Microsoft OS is, in fact , an open source, like RTOS, As far as I know, a lot of lightweight, bottom-level frameworks will choose to base on these OSs.
It won't be used on Linux.
As far as I know.
But of course I don't know a lot of products.
The advantage is, to be honest, lightweight.
And after all, it's open source.
It's directly used.
I think those of them...
Because this should be a real-tech development framework.
Maybe the developers didn't know the features of HIP are like this.
Got it.
Thank you.
OK.
Anyone else has questions?
Hi, Jiang.
I have a question.
Your supervisor told you that you can research in this direction.
And then you really dug out these things.
I want to ask a more realistic question.
Did your company give you any extra reward?
Oh, that's a good question.
Actually, this is different from the company's policy.
Actually, before I went in, Ms.
Sun had already discussed it internally.
That is to say, if you find a loophole internally, are you going to deal with it like the external loophole, or just pretend that you didn't find anything and just cover it up?
And the conclusion they came to at that time was to deal with it as an external loophole.
The reason is, if you find a loophole internally, it's better for you to sign up and send an email from outside.
I don't think so.
So, if we find a loophole internally, we will deal with it as an external loophole.
Got it.
Thank you.
Okay, we still have three minutes.
Any other questions?
Please use the microphone in the front.
Okay, I want to ask where did you get the firmware?
The firmware is actually found in the update package.
In the update package of your NAS, you will find a strange name, click on it, and then you can take it apart and look at it.
Oh, that's what I said earlier.
It can be found that this SSH is drop-in, so there is a related GPO code to see if it is this kind of SSH.
Yes, when I was looking at it, most of it was looking at the source code.
Only those that are really exploiting or memory management, I would take it apart and look at it.
So the moving part should be the patch part.
Yes.
Okay, I want to ask about the debug part.
Maybe there will be some error messages coming out during the crash, or there are some filesystems that can look at the current memory status.
Debug is a very interesting thing.
In fact, I used a very advanced technique.
Because this firmware is actually a bit magical.
It was developed by Realtek and then handed over to us, and then we will go on to the subsequent development.
So we don't actually have all the source code.
But since it will be developed by us later, we have a way to build that firmware.
The method I used was to directly change the source code to give me an arbitrary read function.
Then I washed it into the partition, and then I went to look at the memory inside.
Yes, this is a more crooked approach.
A more normal approach should be to plug in a hardware debugger.
I forgot what it's called.
That should be a more normal approach.
Okay, got it.
Thank you.
Yes.
Then we have one minute left, and we can open the last question.
Does anyone want to ask the last question?
If not, that's it for today.
Thank you, Kevin.
Thank you.