Zhongrui: Okay, I'm Li Zhongrui, and here are my colleagues Yi Zhe and Kira.
We are all from DARKNAVY , and today we're gonna share our research on
the recent WhatsApp zero -click attack chain on iOS and Samsung devices.
We will share how we analyze and reproduce the old bugs, as well as
how we find some new vulnerabilities in Samsung's image libraries.
And sorry that my English is not very fluent, so
I will speak as slowly and clearly as I could.
And for this talk, you can take any pictures if you want, and here we go.
And super apps are apps with huge user bases and many
features, like WhatsApp, Signal, WeChat, and iMessage.
Because of their popularities, they are often
the major targets for the nation -state attacks.
So here are some zero -click chains in recent years.
Back to 2019, attackers have used bugs in the WhatsApp VoIP stack with only a phone number.
They can compromise a phone remotely.
And later on, many iMessage zero -click attacks have appeared,
like the fourth entry in 2021. They use malicious PDF files,
and the blast path using the well -known WebP vulnerabilities.
In 2024, it is reported that some attackers used WhatsApp to target
Hamas leader, Haniyeh, get his location and launch an airstrike.
So, we all know that 4 -chain attacks are getting harder and harder.
But actually, national -state attacks still happen almost every year.
So, our story starts from an iOS bug, CVE -2025 -43300. And it is very famous.
I think most of you have heard about it.
It was fixed in iOS 18 .6 .2. And in August, Apple
urgently fixed a bug in the ImageIO framework.
And it may have been exploited in an extremely sophisticated attack.
So we thought this could be a very powerful bug.
And we started analyzing it right away.
We did a bin diff on the Mac OS between 15 .6 and 15 .6 .1.
And we found that ImageIO framework did not change a lot.
But the raw camera bundles have changed a lot.
And after a deeper analyze, we found two main functions get security patches.
The one is the DNG lose the unpacker, and the other one is the news list JPEG unpackers.
And anyway, it was clear that these patches are mainly about DNG decompression functions.
And so first, before I introduce any security stuffs,
let's have a quick introduction to the DNG format.
So DNG mainly stores raw images. It is basically an extension of the tape format.
An image file has three main parts. A header for byte order and a version.
IFDs, which is the image file directories, contains
metadata like width, height, and compression.
And the data area that stores raw pixels, it is usually compressed.
And an image is made of pixels.
A pixel is the smallest unit, and it is usually not just one number.
It contains some channels. And samples per pixels.
This metadata means how many channels are in one pixel.
For example, RGB has three samples, red, green, and blue.
And bits per sample means how many bits are used for one channel value.
And one bit is just black and white. And eight bits is common.
And 16 bits is higher equality. And actually, data in raw files are huge.
Therefore, the data inside the DNG format are often compressed.
The DNG supports these compression methods. The one is for uncompressed.
The seven is loss less JPEG, and the last one is lossy JPEG.
And finally, DNG can also include some opcode lists.
This adds extra processing steps during the parsing logic. There are three stages.
One after the reading the new raw data, and after linear mapping, and after demosaicing .
And there are 30 opcodes in total, each with different functionalities.
And it's really easy to make some mistakes in opcode handling.
And we will come back to it later. And next, let's introduce the attack vector.
And different vectors, different apps can trigger the same bug in different ways.
For example, the preview goes through the image kit.
And while other apps may go through UI kit.
In the end, they both call image IO APIs to render some images.
Then through the core graphics and the core images.
And finally, we will trigger the bugs in the raw camera implementations.
So back to the raw camera diff.
Apparently, the patches for the lossy unpacker was much easier to read.
And the lossless part was much more complex.
So we'll start with the lossy unpacker first. And the patch was very clear.
In the old version, it multiplies tile width and height.
In the new version, Apple added a check at each
step using 128 -bit calculations to detect overflows.
So it looks like that Apple wanted to eliminate an integer overflow here.
So it looks very simple. So we just tried it right away.
We added a DNG file and made the width and height very large to trigger overflows.
But it was not that simple. Before reaching that code, there was an earlier check.
The tile width and height cannot be larger than 20
,000. And with that limit, the product won't overflow.
So this did not sound like the real bug.
But we, after several rounds of guessing and randomly
playing with the metadata, we finally triggered a crash.
And that made us very excited. And the bug was simple.
Just while we played with the DNG metadata, we found that the
unpacker didn't check the product of image width and image height.
We changed them from a very small value to a big
one like the 0x6000. So the product became negative.
And we got out of bounds read and write finally to trigger a crash.
So is this zero days? Unfortunately, no.
This was an old bug fixed in 15 .4. But we tested
the old Mac OS 15 .2. So we found my mistakes.
So, but still, ImageIO is a very active attack surface anyways.
And so what is the real bug behind this sophisticated attack chains?
On the same day, we found the old bug.
The battery boy posted a short analysis and working POC for this bug.
He started from a dog photos.
It is a lossless DNG file from a photo gallery website.
And then he changed only two bits.
The samples per pixel from one to two, and the non -components from two to one.
And we still don't know how he found this trick, but it
triggered an OOB crash in the lossless JPEG unpackers.
So there have been many analyses of these
vulnerabilities, such as the blog post from the Corks lab.
So we just will briefly summarize it.
And this is a simple view of the unpacker functions.
Firstly, it allocates a buffer based on the width times height times samples per pixel.
And to store the decompressed output. And then it loops over height and width.
So actually, it visits every pixel.
For each pixel, it loops over channels and decompresses the data for the channels.
And the bug is that the real pixel size in the unpacker is the NUM components.
So for one row, the loop limit should be width times NUM components.
But actually, it is hard coded as width times 2.
So when NUM components is 1, the loop runs about twice as many times as it should.
So here is a simple example. The original image is 2 times 2 DNG with 2 channels.
So the buffer size is 8.
Each time a pixel is traversed the two channels of data are decompressed.
But because the width times 2 x 4, the loops will run over eight times.
But the first four times, the writes will exceed the buffer.
So the rest becomes an out -of -bounds write. So it causes overflows.
So we wonder that, is this DNG bug used in another typical iMessage attack?
The answer was surprising.
On the last day of August, the WhatsApp released a security update.
It was very clear that this bug was used in a real WhatsApp -in -the -wild attacks.
So next, my colleagues, Yizhe, will introduce how we
analyze and reproduce the WhatsApp zero -click attack.
Oh, hi, everyone. And now I'm going to talk about this CVE -2025 55177.
And it's the zero -click vulnerability of WhatsApp, iOS, iPadOS, and iPadOS.
Okay, let's start. Let's first talk about the zero -click attack surface.
The zero -attack surface in WhatsApp can be roughly divided into three parts.
The first one is the protocol handling.
There are some complex protocols like VoIP, RTP in WhatsApp.
There are a lot of states in these protocols, and there are some attack surfaces.
And then comes the file format parsing.
Something like forms, images, and the documents, all these kinds of attack surfaces.
And finally, it's the message process. WhatsApp deals with messages it receives.
And if there are some problems like deserialization,
error, or improper handling, it may cause vulnerabilities.
And today, the issue we talk about is the last one that is the improper handling.
Now, let's come back to the advisory.
We can see that this CVE has a very detailed advisory.
And we can see that the vulnerability of WhatsApp is fixed in 21 .73 version.
And as a security researcher, of course, I want to check that the
last version was this vulnerability and perform some patch analysis.
So I went to the App Store.
And we can see the previous version was 20 .84, skipping a lot of
versions, which means that M eta does a lot of inner version iterations.
And there must be a lot of function updates.
And maybe it's difficult to do the patch analysis.
But nevertheless, we can still have a try.
There are two main binaries in WhatsApp.
The first one is the main program, WhatsApp, and
the shared library called the shared modules.
As we can see, there are totally about millions of functions in these binaries.
And a certain of them are different.
And it's hard to find the real vulnerabilities without any information.
So the patch analysis approach is not working. So we turn back.
Since there is a detailed advisory, we are trying to find the vulnerability again.
So let's come back to the advisory.
We can see that there are two interesting points in the advisory.
Firstly, the vulnerability is about the incomplete authorization of linked devices.
Linked devices refer to the WhatsApp devices using the same account.
And secondly, the vulnerability is not about the messages with the image.
It's weird because we know that the subsequent chain uses the DNG parsing vulnerabilities.
But instead, it is about the processing content from an arbitrary URL.
And that's very interesting.
So let's quickly take a look at the content of WhatsApp message.
The WhatsApp message is encoded in its own format.
And since there is a web client of WhatsApp, it can be easy to reverse.
And thanks to WPP Connect team for releasing a lot of tools to do the reversing.
By the way, these screenshots were obtained from the GitHub repository.
We can see that the messages is encoded in Protobuf.
And there are many types of messages, such as
image messages, document messages, and et cetera.
These message types can also be composed with a lot of components.
And now, let's see how we can turn a URL to an image.
It naturally came to me that URL preview is a very promising entry.
Firstly, when you input some text in WhatsApp client like
this, FDR is a URL in the text, then WhatsApp will try to
fetch the content from the web page and generate a subnail.
However, this subnail is not generated on the web server or on the receiver.
It's just on the sender.
It means that the sender downloads and passes
the image, and then it will generate a subnail.
Then you send an extended text message to the, as you can see in this
Protobuf definition, and the receiver will receive something like this.
The message contains just a thum bnail instead of the original image.
So it's not quite the same with the advisory, because it says that
the URL parsing happens on the targeted devices instead of the sender.
So the common URL preview features may not be what we want.
There must be something more interesting.
So after some attempts, we found this request URL
preview message type in the Protobuf definitions.
So what is this kind of message, and why WhatsApp clients need this? Let's see.
Because we all know that mobile devices or PC devices, they
have their own system libraries or web views to do the URL
preview, and that they can generate the thumbnails themselves.
However, when it comes to web clients, they cannot simply
preview the URL and generate the thumbnail themselves.
So they need the help of the linked devices.
To check it, there is an easy way that if you input something in
your web client and put your phones in the flight mode, then you
will see that your web client cannot preview the URL anymore.
And then let's see how the whole process works.
Firstly, if you input something in the web client,
it will generate a preview request like this.
You can see that the URL argument is in the request.
This is a peer data operation request, so it will be sent to the linked device.
And the linked device will then fetch the target
URL and generate the corresponding thumbnail.
And you can see at this time, the linked device does not require any user interaction.
It will automatically pass the image, generate
the thumbnail, and send it back to the web client.
And finally, the web client will send the message with JPEG thumbnail.
We can see that in this process, linked devices
act as a server, and it helps to pass the image.
So it may be the attack target of the zero click chain in the wild.
So we know that this is a kind of peer message, and it's originally
supposed to be sent only to the device logged in the same account.
So there's a problem that is this kind of message be able to be sent to other devices.
Let's come back to the message transmission of WhatsApp.
This is just a simple illustration.
The actual transmission process is far more complex,
and we are not talking about it at this time.
So we can see that firstly, the sender and the receivers have a pre -shared key,
and the sender just used JID, that is the phone number of the recipients account,
and then encrypt the message with the pre -shared key and send it to the server.
The server just forwards the message based on the phone number to the receiver.
And finally, the receiver decrypts the message with the pre -shared key.
That's why we say this message is end -to -end encrypted.
So we know that just knowing the phone number messages can be sent to anyone.
So if I'm an attacker, I can forge a request URL pre
view message and just send to anyone I want to attack.
And the targeted device acts as a linked device, and it will
try to fetch the malicious URL passing the malicious DNG and
trigger the DNG vulnerability without the user being aware.
Since we know that the message is end -to -end
encrypted, the server cannot retrieve the message.
So the server cannot check the content you send is in the correct format.
Only client -side check can prevent the search messages from being processed.
So let's see how the client checks the peer messages.
After some reversing, I found the short process payload function.
It determines whether to handle this message or not.
If this message should be handled, it will return true.
Otherwise, it will return false.
The function firstly checks that if this message is posted from peer.
The messages from peer device are always trusted, so it returns true.
And then if the message is not sent from the peer
device, it will check if there's a portal message.
This function only considers protocol messages, and if
it is not a protocol message, it continues the process.
And finally, it will check whether the message type is on a
whitelist, as you can see on the screenshot showed on the right.
To see what messages types correspond to these numbers,
you can refer to the following protobuf definition.
The peer data operation request message types correspond to 16, which is in the whitelist.
Going through the entire process, we can see that the peer messages
will always be handled, even if it is received from others' devices.
Thus, we can forge this kind of message and send it to anyone we want.
However, there are still some problems when we reproduce the vulnerabilities.
We can see when WhatsApp client fetch the image, it sets a range in the HTTP
request header, requiring that the image size must be less than the limit.
However, the PoC we just created in the previous part was modified on a real
DNG image, which is very large, with a size of about several tens of megabytes.
Therefore, we have to generate the DNG files of the appropriate size of shelves.
Then, we patch a third -party client to send a message to
trigger the vulnerabilities and reproduce the problems.
Here is the demo.
First, we check the versions of the client on macOS, iOS, and iPadOS.
Then, we log in the attacker's account.
This account is not related to the victim, and it's not added to the contact.
And then, input the phone number we want to attack.
And then, the victim device is fetched the images.
As you can see, the server receives the request, and then, boom.
We can see the crash vault.
It has crashed in the image I O, which proves that
we really triggered the DNG vulnerabilities.
And finally, let's see how WhatsApp fixed the problem.
The upper code is before fix, and the one below is after fix.
We can see that WhatsApp adds a check for these kinds of messages.
The messages types like peer data operations need additional checks afterwards.
With this patch, WhatsApp clients only process messages of these types from linked devices.
While we are analyzing these vulnerabilities, we also notice that
Meta posts a bug report to Samsung about the QRAM image library.
It's Samsung's system library to parse the DNG file.
We wonder if these DNG vulnerabilities can be triggered in the same way on Samsung.
So, we did a little reversing on WhatsApp .apk.
And we can see that when parsing image, WhatsApp uses the Bitmap Factory.
And it is built with the LibDNG SDK and will not call the QRAM Lib Samsung uses.
So, the Samsung's exploit chain may not use this vulnerability of the peer message.
This is all my part of WhatsApp's zero -click vulnerabilities.
Next, let's welcome my colleague, Kira, to
introduce our research on Samsung DNG vulnerability.
Hello, hello. Hello, everyone.
I'm Kira, and I will introduce the Samsung part of this story.
First, in September, we first came across this security
advisory, and it immediately caught our attention.
In this advisory, Samsung mentioned that they were notified
that this vulnerability was already being exploited in the wild.
And they also pointed out that the affected component
was the library called lib -image -codec -qram.
So, our very first reaction was that, wait a second, could this
be the same vulnerability as the one we saw on iOS last month?
So, naturally, the next thing we did was download the
firmware, extracted the library, and run bin diff on it.
And luckily, Samsung was very generous.
The symbols in this library were still available.
So, that made the bin diff process extremely clear and easy to read.
W hat we found was that the differences weren't actually that many.
The number of functions that really differed was pretty limited.
Basically, just the ones you can see here in this picture.
Then, we identified roughly about three major differences.
And the first one shows up in the OP code map table initialize function.
As my colleague, Zhong rui, mentioned earlier, inside
a DNG file, there is something special called OP code.
And when the parser starts processing these OP codes, the first
thing it does is initializing how many OP codes exist in the image.
Based on that number, it will allocate a vector to store them.
Here on the slides, you can see the version before the patch
on the left and the version after the patch on the right.
The key change is that they added a sanity check.
The OP code count must be less than or equal to one million.
And after that, the rest of the logic stays the same.
It simply creates elements according to the OP code count and pushes them into the vector.
Then, let's move to the second diff.
This check is in the OP code list, especially inside the doApply function.
This is the place where the OP code actually gets applied.
For example, if an OP code represents a crop operation,
the real logic is executed inside this doApply function.
And again, in the patched function, they added an extra validation.
The OP code type is now required to be less than or equal to
0xd, which means the OP code type must fall between 1 and 13.
In other words, unknown OP code types are no longer allowed to apply.
And here's the third difference.
This one appears during the initialization of an unknown OP code.
What it does is place a limit on the size field of the OP code.
It has to be smaller than a certain value, which is actually still quite large.
And it's roughly about 3 million in hex.
And so if we take a step back, these were the
three most obvious patches we saw at that time.
There were also a few smaller changes, but these three really stood out.
And honestly, this is where we got pretty confused because none of these
three patches seemed to be directly related to the actual vulnerability.
So while we were still stuck there, we were trying to figure
this out, someone on X suddenly jumped in and posted a tweet.
They said, this is actually pretty obvious, the
vulnerability is right at that 1 million check.
Do you remember the first patch I just talked about?
And someone else replied and asked, so is the out of
bounds happening because the OP code count is too large?
And they even said, yes, apparently.
But when we actually looked at the code more
carefully, his interpretation didn't really hold up.
What's happening here is that the count is only being used to allocate a vector.
In other words, this check is to limit the capacity of that vector.
So it doesn't directly introduce a vulnerability.
Essentially, it just prevents a DNG image from
allocating an excessively large amount of memory.
And if you do the math, one million entries is roughly on the order of a megabyte.
Even if each OP code took a few dozen bytes, you are still only talking about a
few tens of megabytes, which really isn't that large memory for modern cell phones.
So from our perspective, this check is mainly there to restrict heap spraying.
It looks much more like a mitigation against exploitation
rather than a fix for the actual vulnerability itself.
And the other two patches fall into the same category.
They are also about limiting the attacker's ability to
exploit the bug rather than addressing the true root cause.
So at that point, what can we do next?
We had these three patches, but none of them really look like a real vulnerability.
So honestly, we decided to stop overthinking it and just try debugging something.
The first thing we wanted was to build a PoC and see if we could trigger a crash.
Our idea was based on the second patch.
Originally, there was no proper limit on the size field.
So our thinking was, what if we allocate an extremely large
size and force the new operation to return a null pointer?
And then we can hit null pointer dereference in the following code.
So that was our initial hypothesis.
So we constructed a DNG that was about two gigabytes in
size and fed it into the library to see what would happen.
And yeah, the image was actually constructed and loaded by the library.
Then what happened? And yeah, as our expected, it did crash.
But if you take a closer look at the crash stack
trace, this might be a bit hard to see on the slide.
But there is a line I highlight here in the middle
showing the fault address causing the crash.
And that address is something like 0xb4, blah, blah, blah, which is clearly a heap address.
So even though the program crashed, it didn't crash in the way we expected.
So the question is why the crash wasn't caused by a null pointer dereference at all.
So we decided to dig much deeper and really debug this issue.
And then we ended up discovering a true zero day.
That's exactly what the title refers to, the birth of this zero day.
And we started by analyzing the crash using the stack backtrace.
As you can see here, the crash happens inside the function QuramD ngS tream::G etD ata.
This function is used almost everywhere in the library when it reads a dng image.
Basically, nearly all file read operations eventually go through this function.
The logic is fairly simple.
It reads a requested size, but internally it processes the data in step of
0x1000 using an intermediate offset to track how much has already been read.
And that's where the problem is. This offset is stored as an integer.
Each iteration adds about 0x1000 to it.
And because it's a 32 -bit integer, once it reaches
around 0x7FFF, it overflows and it becomes negative.
So at that point, the code ends up performing a memory copy
to a very large negative offset, which is an obvious heap
out of bounds access, and that's what caused the crash.
At that point, we still didn't really know what this vulnerability actually was.
So we just kept testing, and as we continued testing, we hit another crash.
And this is the birth of another zero day.
This happened when we tried to reuse an existing PoC for the dng vulnerability on iOS.
Our initial idea was very simple.
We would like to just take the iOS dng sample and
run it on Samsung, but that didn't work at all.
The file wouldn't even load at first.
So we tried to adapt the iOS vulnerability dng into a version
that Samsung would accept, just to see how it behaved.
And yes, it did crash again.
But this time, when we look at the stack back trace, something felt off.
The crash was happening inside an OP code called fix bad pixels constant.
That immediately raised a red flag. Why would it crash here?
So once again, we went back and did a deeper analysis.
And sure enough, we had found yet another zero day.
And in the end, these two zero days had different outcomes.
One of them was rated as higher severity by Samsung,
while the other one was marked as a duplicate.
And we later confirmed that this duplicate was collided with Brandon from Project Zero.
He has been finding quite a lot of issues in Samsung's Q -RAM library recently.
And as far as we understand, this particular issue may not
be fully patched yet, according to some official information.
And it's expected to be disclosed maybe next week.
So let's take a step back and recap the whole story.
First, back in August, Apple and Meta released the
patches to fix the zero -click vulnerability chain.
Then if we look at the Samsung timeline, the
vulnerability was actually reported much earlier.
In September last year, Samsung stated that they had received a report from Meta.
However, the issue wasn't fixed until more than half a year later, around April this year.
And interestingly, the CVE ID itself wasn't assigned until this September.
Then about two weeks ago, on December 13th, Project Zero published a blog post
that went into very detail about how this vulnerability was exploited in the wild.
So let me briefly summarize what this bug actually looks like.
The one natural question is that why didn't we catch it during our earlier bindiff analysis?
The reason is that the patch was extremely subtle.
It only added a single multiplication.
In the bindiff results, the similarity score was 0 .99.
T o the naked eye, the two versions looked almost identical, basically the same.
So we ended up overlooking it at that time.
As for how the exploit works, the attacker somehow needs to
get the victim to save a malicious DNG image onto their device.
On Samsung devices, there's a service called IP service.
This service periodically scans images stored on the phone and
performs analysis on them, most likely for AI -related features.
During this analysis process, it naturally passes DNG images.
And that's exactly where the attack happens.
While passing the malicious DNG, the IP service gets compromised by the attacker.
What's also interesting is that there's actually another chain in this whole story.
If you look at Samsung's advisory from September,
you can see that the CVE IDs are consecutive.
One is 21042 and the other is 21043.
This indicates a completely new exploit chain,
meaning Samsung was attacked again in this year.
But if we go back to the chain that was fixed in April, Samsung never
stated in their advisory that it was being exploited in the wild.
And on top of that, the CVE ID for that issue wasn't even assigned until this September.
So from the CVE numbering alone, you can already tell that these issues are closely related.
As for us, we started our analysis after Apple released their advisory.
And during that process, we reported two vulnerabilities
ourselves and the managers to reproduce the iOS chain.
At the same time, Project Zero was independently analyzing and reporting similar issues.
They've reported many DNG -related vulnerabilities to Samsung so far.
And most of those were finally patched in the most recent advisory released this December.
So in reality, the story still has a lot of unanswered questions.
And honestly, that's the part we find most fascinating.
In Samsung's exploit chain, how exactly the zero -click part
was achieved, no one really knows how that step worked.
And it also raises another question, were there
actually two different zero -click vulnerabilities?
One used last year and another one used this year? Or was it the same bug?
We seemingly don't know.
Even though Project Zero published a detailed blog post, they analyzed the
WhatsApp vulnerabilities they discovered, but they still are not sure whether
the bug corresponds to the zero -click entry point in the exploit chain.
So in the end, the story is far from over.
There's still a lot left to uncover and a lot more to dig into.
And finally, let's take one last look at Samsung's
history with the zero -click vulnerabilities.
About five years ago, one of the earliest Samsung zero -click attacks was demonstrated
by Project Zero's Juro, who built a demo targeting Samsung's MMSS service.
That attack exploited a Samsung -specific image format called QImage.
Now, fast forward five years, and we are looking at
the same vendor and the same image passing library.
At first, I wanted to compare the two chains in detail and analyze how they differed.
But in the end, I realized that that wasn't even necessary,
because Project Zero already summarized it perfectly.
Their conclusion was that except for some ASLR bypassing tricks and a little
bit of JLP, no mitigations posed a significant hurdle for the attackers.
So when you look at this, even after five years, there hadn't
been a fundamental change for zero -click attacks like this.
The overall status hadn't really evolved that much at all.
So let's take a final look at the history of zero -click exploit chains.
Last year, also at the CCC conference, Boris disclosed the operation
triangulations, which exploit vulnerability in TrueType font passing.
And the year before that, we analyzed the libwebp
vulnerability, which was a bug in webp image passing.
And going even further back, there was the PDF passing vulnerability in iOS.
And this year, we believe that there were at least three
different exploit chains, all targeting the DNG image passing.
So what has actually changed in terms of mitigations?
If we look at the applications like WhatsApp, many modern
protections such as PAC, the BTI, CFI are largely absent.
These defenses tend to be more thoroughly deployed in first -party system
applications like iMessage, where security is given a much higher priority.
But for third -party applications, they are still developed by the device vendor themselves.
Uh, they are NOT developed by the vendor themselves.
So these protections still lag behind. And the same goes for the sandboxing.
And finally, we have MTE. Google has already introduced the MTE since Pixel 8.
But rolling it out broadly and effectively across the whole
ecosystem will still take a significant amount of time.
So as security researchers, we still have a long road ahead of us.
There's plenty of work left for us to do. And that's all. Thank you for listening.
Awesome. Thank you for those interesting insights.
Can you please wait a little bit, be quiet if you go outside?
Let's have a look to the stage management. Do we have some time left? Yes.
We have 10 minutes for questions.
If you have questions, we have placed microphones in the
middle, right in the front here and in the back there.
If you are not able to stand up and want to ask a question, give us a sign.
We pass you a microphone. Can the rest be quiet, please? Thank you. Okay.
Questions? No? Okay. Do we have questions from the internet?
Microphone number two.
Yeah. Wonderful speech. Thank you so much. Very interesting work.
So I have a question about this Samsung library.
Is this library specific to Samsung or is it a
part like also for Android open source project?
Kira: It's specific for Samsung only.
It's developed by the third party provider for Samsung.
So they actually in Samsung's cell phones, they had two image passing libraries.
The one is the default for Android, which is libhwui and another is this libqramp.
Yeah. Thank you. Thank you so much.
Kira: Thank you.
Okay. More questions? Any questions from the internet? Okay. I think that's it.