ACM SURE Workshop
@sureworkshop.bsky.social
The Workshop on Software Understanding and Reverse Engineering (SURE). Co-located at ACM CCS 2025 in Taiwan. https://sure-workshop.org/
CCS has come to a close, and so has the first-ever SURE Workshop. We want to thank the authors, the PC, @moyix, our panel, and CCS for making SURE a success. We felt the support for this research area (the room was packed out for more than half the day).
See you all next year!
See you all next year!
October 17, 2025 at 3:57 PM
CCS has come to a close, and so has the first-ever SURE Workshop. We want to thank the authors, the PC, @moyix, our panel, and CCS for making SURE a success. We felt the support for this research area (the room was packed out for more than half the day).
See you all next year!
See you all next year!
In the special sub-area of type inferencing on binary code, Noriki's work explores the recovery of structs and how different GNN architectures may have better performance.
October 13, 2025 at 8:11 AM
In the special sub-area of type inferencing on binary code, Noriki's work explores the recovery of structs and how different GNN architectures may have better performance.
On our last presented work at SURE, we have Noriki Sakamoto presenting "Toward Inferring Structural Semantics from Binary Code Using Graph Neural Networks"
October 13, 2025 at 8:11 AM
On our last presented work at SURE, we have Noriki Sakamoto presenting "Toward Inferring Structural Semantics from Binary Code Using Graph Neural Networks"
Indeed, LibIHT is more robust. They achieve better results on binaries that attempt to evade their analysis.
October 13, 2025 at 7:52 AM
Indeed, LibIHT is more robust. They achieve better results on binaries that attempt to evade their analysis.
We're so back, and on our last session: Applications & Future Work.
Changyu "Thomason" Zhao is presenting "LibIHT: A Hardware-Based Approach to Efficient and Evasion-Resistant Dynamic Binary Analysis".
He is presenting virtually.
Changyu "Thomason" Zhao is presenting "LibIHT: A Hardware-Based Approach to Efficient and Evasion-Resistant Dynamic Binary Analysis".
He is presenting virtually.
October 13, 2025 at 7:52 AM
We're so back, and on our last session: Applications & Future Work.
Changyu "Thomason" Zhao is presenting "LibIHT: A Hardware-Based Approach to Efficient and Evasion-Resistant Dynamic Binary Analysis".
He is presenting virtually.
Changyu "Thomason" Zhao is presenting "LibIHT: A Hardware-Based Approach to Efficient and Evasion-Resistant Dynamic Binary Analysis".
He is presenting virtually.
Dongpeng argues that many modern works in deobfuscation don't work on large complex programs. Instead, they are mostly tested on toy programs that are not real-world.
To make a more useful evaluation, they explore how real obfuscation is used.
To make a more useful evaluation, they explore how real obfuscation is used.
October 13, 2025 at 6:58 AM
Dongpeng argues that many modern works in deobfuscation don't work on large complex programs. Instead, they are mostly tested on toy programs that are not real-world.
To make a more useful evaluation, they explore how real obfuscation is used.
To make a more useful evaluation, they explore how real obfuscation is used.
We're on our last talk of the session, remaining with the obfuscation topic. Dongpeng Xu is presenting "DEBRA: A Real-World Benchmark For Evaluating Deobfuscation Methods" in the place of Zheyun Feng.
October 13, 2025 at 6:58 AM
We're on our last talk of the session, remaining with the obfuscation topic. Dongpeng Xu is presenting "DEBRA: A Real-World Benchmark For Evaluating Deobfuscation Methods" in the place of Zheyun Feng.
Some results: you train on obfuscation, and it turns out the model does do better (with BinShot) on obfuscated code. However, training it on specific types of obfuscation tech matters. For instance, training on control flow flattening may not help at all with MBA.
October 13, 2025 at 6:38 AM
Some results: you train on obfuscation, and it turns out the model does do better (with BinShot) on obfuscated code. However, training it on specific types of obfuscation tech matters. For instance, training on control flow flattening may not help at all with MBA.
Next up is "On the Learnability, Robustness, and Adaptability of Deep Learning Models for Obfuscation-applied Code," presented by Jiyong Uhm of Sungkyunkwan University.
October 13, 2025 at 6:38 AM
Next up is "On the Learnability, Robustness, and Adaptability of Deep Learning Models for Obfuscation-applied Code," presented by Jiyong Uhm of Sungkyunkwan University.
Let's start with variable/property naming inside of decompilation. Given many different choices for the same name, does one lead to an LLM or a human to make a decision that is more correct or predictable?
October 13, 2025 at 6:10 AM
Let's start with variable/property naming inside of decompilation. Given many different choices for the same name, does one lead to an LLM or a human to make a decision that is more correct or predictable?
Speaking of evaluating things, how do you evaluate if your decompilation (or other tool) is actually helping you more in understanding software?
Florian Magin is back to present:
"Towards Scalable Evaluation of Software Understanding: A Methodology Proposal"
Florian Magin is back to present:
"Towards Scalable Evaluation of Software Understanding: A Methodology Proposal"
October 13, 2025 at 6:10 AM
Speaking of evaluating things, how do you evaluate if your decompilation (or other tool) is actually helping you more in understanding software?
Florian Magin is back to present:
"Towards Scalable Evaluation of Software Understanding: A Methodology Proposal"
Florian Magin is back to present:
"Towards Scalable Evaluation of Software Understanding: A Methodology Proposal"
One problem is not every one is speaking the same language. Some decompiler report types as a QWORD some say Int some say undefined.
Vedant's work normalizes these differences to make the evaluation more fair.
Vedant's work normalizes these differences to make the evaluation more fair.
October 13, 2025 at 5:52 AM
One problem is not every one is speaking the same language. Some decompiler report types as a QWORD some say Int some say undefined.
Vedant's work normalizes these differences to make the evaluation more fair.
Vedant's work normalizes these differences to make the evaluation more fair.
New session, who this? In this session, we are talking about benchmarking! We start with "Benchmarking Binary Type Inference Techniques in Decompilers," presented by Vedant Soni.
October 13, 2025 at 5:51 AM
New session, who this? In this session, we are talking about benchmarking! We start with "Benchmarking Binary Type Inference Techniques in Decompilers," presented by Vedant Soni.
We had some technical issues, but the "spark notes" give us a good overview: these higher-level languages are being used at scale in real systems and they post a real problem.
October 13, 2025 at 4:03 AM
We had some technical issues, but the "spark notes" give us a good overview: these higher-level languages are being used at scale in real systems and they post a real problem.
But how usable is the recovered Swift (or other language) code? You can get a good guess by asking LLMs to do tasks with the decompilation.
October 13, 2025 at 3:45 AM
But how usable is the recovered Swift (or other language) code? You can get a good guess by asking LLMs to do tasks with the decompilation.
Applying this, ideco turns Swift code that is represented as C (150 lines) into something that is significantly shorter.
October 13, 2025 at 3:45 AM
Applying this, ideco turns Swift code that is represented as C (150 lines) into something that is significantly shorter.
Well, ideco creates a framework for describing the language you actually want to decompile to (like Swift) and attempts to turn the decompilation into that!
How is it done? With a Domain Specific Language (DSL)!
How is it done? With a Domain Specific Language (DSL)!
October 13, 2025 at 3:44 AM
Well, ideco creates a framework for describing the language you actually want to decompile to (like Swift) and attempts to turn the decompilation into that!
How is it done? With a Domain Specific Language (DSL)!
How is it done? With a Domain Specific Language (DSL)!
His motivation is this: a near 15-line Swift program, when decompiled into C, is now around 150 lines. That is a 10x increase! And it sucks.
So, what can we do about it?
So, what can we do about it?
October 13, 2025 at 3:44 AM
His motivation is this: a near 15-line Swift program, when decompiled into C, is now around 150 lines. That is a 10x increase! And it sucks.
So, what can we do about it?
So, what can we do about it?
Speaking of decompilation, that is not just C; we are now on "ideco: A Framework for Improving Non-C Decompilation," presented by Sam Lerner, an independent researcher.
October 13, 2025 at 3:44 AM
Speaking of decompilation, that is not just C; we are now on "ideco: A Framework for Improving Non-C Decompilation," presented by Sam Lerner, an independent researcher.
But how usable is the recovered Swift (or other language) code? You can get a good guess by asking LLMs to do tasks with the decompilation.
October 13, 2025 at 3:44 AM
But how usable is the recovered Swift (or other language) code? You can get a good guess by asking LLMs to do tasks with the decompilation.
Applying this, ideco turns Swift code that is represented as C (150 lines) into something that is significantly shorter.
October 13, 2025 at 3:44 AM
Applying this, ideco turns Swift code that is represented as C (150 lines) into something that is significantly shorter.
Well, ideco creates a framework for describing the language you actually want to decompile to (like Swift) and attempts to turn the decompilation into that!
How is it done? With a Domain Specific Language (DSL)!
How is it done? With a Domain Specific Language (DSL)!
October 13, 2025 at 3:43 AM
Well, ideco creates a framework for describing the language you actually want to decompile to (like Swift) and attempts to turn the decompilation into that!
How is it done? With a Domain Specific Language (DSL)!
How is it done? With a Domain Specific Language (DSL)!
His motivation is this: a near 15-line Swift program, when decompiled into C, is now around 150 lines. That is a 10x increase! And it sucks.
So, what can we do about it?
So, what can we do about it?
October 13, 2025 at 3:43 AM
His motivation is this: a near 15-line Swift program, when decompiled into C, is now around 150 lines. That is a 10x increase! And it sucks.
So, what can we do about it?
So, what can we do about it?
Speaking of decompilation, that is not just C; we are now on "ideco: A Framework for Improving Non-C Decompilation," presented by Sam Lerner, an independent researcher.
October 13, 2025 at 3:43 AM
Speaking of decompilation, that is not just C; we are now on "ideco: A Framework for Improving Non-C Decompilation," presented by Sam Lerner, an independent researcher.
He starts with a question: If an outer class contains an inner class, is the outer class as big or bigger than the inner class?
Intuitively, it should always be true. But it is not! How? See the paper, a crazy corner case:
sure-workshop.org/ac...
Intuitively, it should always be true. But it is not! How? See the paper, a crazy corner case:
sure-workshop.org/ac...
October 13, 2025 at 3:21 AM
He starts with a question: If an outer class contains an inner class, is the outer class as big or bigger than the inner class?
Intuitively, it should always be true. But it is not! How? See the paper, a crazy corner case:
sure-workshop.org/ac...
Intuitively, it should always be true. But it is not! How? See the paper, a crazy corner case:
sure-workshop.org/ac...