# obfuscation Obfuscation is a software-protection technique that modifies compiled or binary code to make reverse engineering and decompilation more difficult while preserving functionality. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Obfuscation Fundamentals: Applying ProGuard and R8 Protections to Android Code DevFeed: [Obfuscation Fundamentals: Applying ProGuard and R8 Protections to Android Code]() Original publisher: [Read original article]() Author: dustin@dustn.dev (Dustin Summers) Published: 2026-09-17T04:13:15.404035Z Content type: tutorial Language: en Sources: [Dustin Summers]() Topics: [obfuscation](), [Android](), [R8](), [Code]() Tags: [android](), [meetup](), [obfuscation](), [proguard](), [r8](), [video]() ### AI overview A presentation introducing obfuscation with ProGuard and R8, focused on applying protections to Android code. It explains how to diagnose the code entering and leaving these build tools. ### Source excerpt This presentation was given at a MeetUp in DC. It corresponds to this series of blog posts, which is the first in a series to teach about Obfuscation/ProGuard/R8, and will primarily be centered around applying protections to Android Code. Tools such as R8 and ProGuard are available, but to many they are a black box that code goes into and stuff comes out. The following will demystify the black box, and teach developers how to properly diagnose the code going into and coming out of these build tools. ## App Hardening: One Obfuscation Pipeline Across Every Port DevFeed: [App Hardening: One Obfuscation Pipeline Across Every Port]() Original publisher: [Read original article]() Author: Shai Almog Published: 2026-08-15T00:00:00Z Content type: article Language: en Sources: [CodeName One]() Topics: [obfuscation](), [cross-platform](), [Encryption](), [Security](), [Reverse Engineering](), [App]() Tags: [android](), [app](), [cross-platform](), [encryption](), [hardening](), [ios](), [javascript](), [native](), [obfuscation](), [platform](), [r8](), [reverse-engineering](), [security]() ### AI overview Codename One App Hardening applies one pre-build protection pipeline to a merged cross-platform application before it is split into Android, iOS, JavaScript, Windows, Linux, and desktop builds. It supports renaming, eligible string encryption, selected control-flow transformations, verification, and crash-report retracing, while acknowledging that reverse engineering cannot be made impossible. ### Source excerpt Codename One App Hardening applies class and member renaming, string encryption, and platform-safe control-flow transforms before one application becomes Android, iOS, JavaScript, or native desktop output. ## The Hidden Costs of DIY Android App Security | Guardsquare DevFeed: [The Hidden Costs of DIY Android App Security | Guardsquare]() Original publisher: [Read original article]() Author: Michael Olechna - Product Marketing Manager Published: 2026-07-28T13:00:55Z Content type: opinion Language: en Sources: [Guardsquare Blog]() Topics: [Security](), [Android](), [Mobile](), [obfuscation](), [R8](), [Open Source]() Tags: [android](), [dexguard](), [mobile](), [obfuscation](), [open-source](), [protection](), [r8](), [security](), [thought-leadership](), [threat-monitoring]() ### AI overview The article argues that DIY Android app security built around open-source tools can leave important protection gaps. It explains that R8 helps compile and optimize Android applications but is not a complete security solution, lacking capabilities such as string encryption, API endpoint security, and control-flow obfuscation. ### Source excerpt The DIY temptation to build with open-source is strong for mobile app developers. After all, their job is to build, secure, and design new applications, features, and architectures that benefit the users of their apps. ## Mobile App Security Without Sacrificing UX | Guardsquare DevFeed: [Mobile App Security Without Sacrificing UX | Guardsquare]() Original publisher: [Read original article]() Author: Ryan Lloyd - Chief Product Officer Published: 2026-07-21T13:02:06Z Content type: article Language: en Sources: [Guardsquare Blog]() Topics: [Mobile Security](), [Application Security](), [Security](), [obfuscation](), [User experience (UX)](), [Reverse Engineering](), [Jailbreak](), [debug]() Tags: [application-security](), [jailbreak](), [mobile](), [obfuscation](), [performance](), [profiling](), [reverse-engineering](), [security](), [technical](), [time](), [ux]() ### AI overview The article explains how profiling instrumented mobile applications helps teams apply obfuscation and runtime security controls at appropriate levels while limiting effects on stability, performance, and user experience. It also discusses automating application profiling at scale through AI-driven and agentic testing. ### Source excerpt Mobile application security has evolved significantly over the past decade. Modern applications routinely employ code obfuscation, runtime application self-protection (RASP), anti-tampering controls, jailbreak and root detection, debugger detection, certificate pinning, and a variety of other runtime defenses designed to protect intellectual property and sensitive user data. ## Obfuscated Rhythm Games DevFeed: [Obfuscated Rhythm Games]() Original publisher: [Read original article]() Author: Dan Lew Published: 2026-06-23T14:17:46Z Content type: opinion Language: en Sources: [Dan Lew Blog]() Topics: [obfuscation](), [standard]() Tags: [game](), [games](), [music](), [obfuscation](), [standard]() ### AI overview The article examines three rhythm games released in 2025 that intentionally obscure which buttons players should press and when. It discusses how Rift of the Necrodancer, Rhythm Doctor, and Unbeatable derive much of their challenge from less legible note charts and altered visual or auditory cues. ### Source excerpt I've been a rhythm game fiend since my introduction to Dance Dance Revolution in the early 2000s. I spent years obsessed with DDR, took a detour into Beatmania, then played Guitar Hero / Rock Band nonstop for years. I haven't gone deep on any rhythm games recently, ## Chainguard customers safe from Mini Shai-Hulud worm targeting @redhat-cloud-services npm packages with 100K+ weekly downloads DevFeed: [Chainguard customers safe from Mini Shai-Hulud worm targeting @redhat-cloud-services npm packages with 100K+ weekly downloads]() Original publisher: [Read original article]() Published: 2026-06-01T00:00:00Z Content type: news Language: en Sources: [Chainguard: Unchained]() Topics: [npm](), [Security](), [GitHub Actions](), [npm packages](), [GitHub](), [obfuscation](), [payload](), [OpenID connect (OIDC)]() Tags: [chainguard-actions](), [chainguard-libraries](), [endpoint-security](), [github](), [github-actions](), [malware](), [mini-shai-hulud](), [npm](), [obfuscation](), [oidc](), [packages](), [payload](), [red-hat](), [redhat-cloud-services](), [security](), [shai-hulud](), [tokens]() ### AI overview The article reports that the Mini Shai-Hulud worm compromised more than 90 @redhat-cloud-services npm packages through a hijacked GitHub account and GitHub Actions OIDC trusted publishing. The worm spreads tampered packages and malicious workflows, executes an obfuscated payload during installation, and steals cloud, Vault, GitHub, npm, and CI credentials. Chainguard customers using Chainguard Libraries for JavaScript and Chainguard Actions were unaffected. ### Source excerpt A new npm worm hit 90+ Red Hat packages. Chainguard customers stayed protected by blocking install-time scripts and hardening CI/CD workflows. ## Sednit reloaded: Back in the trenches DevFeed: [Sednit reloaded: Back in the trenches]() Original publisher: [Read original article]() Author: ESET Research Published: 2026-03-10T09:58:00Z Content type: article Language: en Sources: [WeLiveSecurity]() Topics: [apt](), [Cloud](), [obfuscation](), [PowerShell](), [Code](), [Network](), [Open Source]() Tags: [apt](), [attacks](), [backdoor](), [cloud](), [code](), [department-of-justice](), [eset-research](), [network](), [obfuscation](), [open-source](), [powershell](), [us]() ### AI overview This article examines the resurgence of Sednit, also known as APT28, and its modern espionage toolkit. It describes the BeardShell and Covenant implants, their use of legitimate cloud providers for command and control and resilience, PowerShell execution, obfuscation, and links to Sednit's earlier tools and operations. ### Source excerpt The resurgence of one of Russia's most notorious APT groups ## Drowning in spam or scam emails? Here's probably why DevFeed: [Drowning in spam or scam emails? Here's probably why]() Original publisher: [Read original article]() Author: Phil Muncaster Published: 2026-01-27T10:00:00Z Content type: article Language: en Sources: [WeLiveSecurity]() Topics: [Security](), [Cybercrime](), [Malware](), [spoofing](), [obfuscation](), [pii](), [data](), [Internet](), [Netflix]() Tags: [cybercrime](), [data](), [digital-security](), [internet](), [malware](), [obfuscation](), [phishing](), [pii](), [scam](), [security](), [spoofing]() ### AI overview This article explains why inboxes can suddenly be flooded with spam and scam emails. It identifies data breaches, leaked personal information, updated phishing kits, spam-filter bypasses, and targeted campaigns as possible causes, and describes risks including credential theft, financial fraud, and malware installation. ### Source excerpt Has your inbox recently been deluged with unwanted and even outright malicious messages? Here are 10 possible reasons - and how to stem the tide. ## Obfuscation Deep Dive: Enhancing R8 and ProGuard for Robust Android Code Protection DevFeed: [Obfuscation Deep Dive: Enhancing R8 and ProGuard for Robust Android Code Protection]() Original publisher: [Read original article]() Author: Kirill Rozov Published: 2025-05-19T07:40:40Z Content type: tutorial Language: en Sources: [Stories by Kirill Rozov on Medium]() Topics: [Android](), [obfuscation](), [R8](), [Reverse Engineering](), [Java](), [Optimization](), [configuration]() Tags: [android](), [configuration](), [java](), [obfuscation](), [optimization](), [proguard](), [r8](), [reverse-engineering](), [security]() ### AI overview This tutorial explains how R8 and ProGuard obfuscate Android applications and why their default naming dictionaries can make reverse engineering easier. It presents custom dictionary configuration, Java reserved-keyword names, invalid Windows filename names, and per-build randomized dictionaries, while noting compatibility and testing risks. ### Source excerpt Obfuscation is a crucial aspect of securing Android applications. While tools like R8 and ProGuard are commonly used, their default configurations primarily aim to reduce app size rather than fortify code against reverse engineering. This article delves into advanced obfuscation techniques to make reverse engineering harder. Understanding Obfuscation Obfuscation transforms readable code into a form that's difficult to interpret. For instance, UserManager might become a, and getUser() could be renamed to b(). R8 and ProGuard perform obfuscation alongside code shrinking and optimization. # R8/ProGuard default dictionary a b c ... z These tools use dictionaries to generate new names, typically starting with single letters (a to z) and progressing to combinations like aa, ab, etc. While this approach minimizes file size, it has drawbacks: Predictable Naming: Limited name variations make it easier to deduce original identifiers. Consistent Builds: Repeated builds produce identical obfuscated names, aiding pattern recognition. Simplified Reverse Engineering: Tools can exploit naming patterns across builds. To counter these issues, customizing the obfuscation dictionary is essential. Implementing Custom Dictionaries R8 and ProGuard allow the use of custom dictionaries via configuration files: # proguard-rules.txt # Add to R8/ProGuard config file -obfuscationdictionary obfuscation-dictionary.tx -classobfuscationdictionary class-dictionary.txt -packageobfuscationdictionary package-dictionary.txt By providing unique dictionaries, you can generate diverse and unpredictable obfuscated names. Advanced Dictionary StrategiesJava Reserved Keywords Using Java's reserved keywords (e.g., if, for, class) as obfuscated names can confuse decompilers, as these are invalid identifiers in source code but acceptable in bytecode. # Java Reserved Keywords dictionary do if for int new ... instanceof synchronized Example of deobfucated Java code with java reserved keywords dictionary package cla ## 4M Models Scanned: Protect AI + Hugging Face 6 Months In DevFeed: [4M Models Scanned: Protect AI + Hugging Face 6 Months In]() Original publisher: [Read original article]() Author: Sean Morgan Published: 2025-04-14T00:00:00Z Content type: article Language: en Sources: [Hugging Face - Blog]() Topics: [hugging face](), [Machine Learning, Security Attacks](), [Threat Research](), [Security](), [threat detection](), [Zero Trust](), [obfuscation](), [vulnerability](), [payload](), [Script](), [llamafile](), [Tensorflow]() Tags: [ai-ml](), [hub](), [hugging-face](), [keras](), [llamafile](), [obfuscation](), [partnerships](), [payload](), [security](), [tensorflow](), [threat-detection](), [vulnerability](), [zero-trust]() ### AI overview Hugging Face and Protect AI report six months of collaboration on Guardian, a scanning system that improves security checks for models hosted on the Hugging Face Hub. Guardian added four detection modules, expanded format and obfuscation coverage, identified a Keras vulnerability, and provides inline alerts and vulnerability reports. The system uses a zero trust approach that treats arbitrary code execution as unsafe, including code hidden through obfuscation. ### Source excerpt We're on a journey to advance and democratize artificial intelligence through open source and open science. ## Crafting Android bytecode analysis tooling using a secret ingredient (Part 1) DevFeed: [Crafting Android bytecode analysis tooling using a secret ingredient (Part 1)]() Original publisher: [Read original article]() Author: Konstantin Zolotov Published: 2024-02-09T11:50:19Z Content type: tutorial Language: en Sources: [Bumble Tech]() Topics: [Android](), [Tooling](), [APK](), [obfuscation](), [R8](), [Kotlin](), [Java](), [Compiler]() Tags: [andriod-app-development](), [android](), [apk](), [bytecode](), [compilation](), [compiler](), [dagger](), [inlining](), [java](), [kotlin](), [obfuscation](), [optimization](), [r8](), [tooling]() ### AI overview This tutorial introduces Android bytecode analysis through DEX inspection and a tool for examining how source-code changes affect compiled binaries. It explains the Android compilation pipeline from Java or Kotlin source through JVM class files and D8-generated DEX files, then describes R8 obfuscation and optimization, including source maps, tree-shaking, inlining, and outlining. ### Source excerpt During the development process, we often focus on the source code but rarely inspect the compiled bytecode. This means we're missing out on a valuable source of information and data for analysis. How? Let's delve into Dex file inspection and build a tool that demonstrates how source code changes impact the compiled binary. Have you ever set R8 rules to obfuscate your app? Have you used an APK analyzer or a diffuse tool to understand how the code is compiled? Are you confident that debug code hasn't leaked into production? There's another potential pitfall: libraries may provide obfuscation rules (e.g., Gson) that merge with the ones in your project. This means third-party dependencies can alter configurations for the entire app. We often assume everything is fine and that we'll notice if something isn't right. But will we? Does this make you feel uneasy? Does it concern you? Because it certainly concerns me. Here, we'll attempt to enhance the situation and enable you to see precisely how your code changes impact the compiled binary. To better comprehend this, let's start with the code compilation process: It all begins with the Java and/or Kotlin source code, which is then compiled into JVM .class files. Note that at this stage, Java and Kotlin compilers can execute annotation processing tools (APT/KAPT) to generate source code (e.g., Dagger), and Kotlin compiler can run plugins to modify the internal code representation. Then, the D8 compiler takes these compiled classes, third-party libraries (JARs, AARs), and converts them into .dex files. However, if obfuscation and/or minification are enabled (which is almost always the case for release builds), R8 comes into play after D8. R8 obfuscates and optimises the bytecode, and additionally, R8 produces a source map file -- a special file listing all the changes and replacements. Obfuscation replaces human-readable names of various entities (classes, functions, fields, etc.) with very short, yet still unique names, for e ## Debugging Proguard configuration issues DevFeed: [Debugging Proguard configuration issues]() Original publisher: [Read original article]() Published: 2021-01-18T00:00:00Z Content type: tutorial Language: en Sources: [Vasya Drobushkov]() Topics: [debugging](), [Android](), [APK](), [obfuscation](), [builds]() Tags: [android](), [apk](), [article](), [build](), [debugging](), [obfuscation]() ### AI overview A tutorial on diagnosing Android release-build bugs caused by Proguard/R8 configuration. It outlines the roles of obfuscation, code optimization, and resource optimization, and recommends using crash logs and APK contents to investigate issues. ### Source excerpt Introduction It might happen so that there is a bug in your release build while in debug everything works fine. In many cases, it might be an issue with Proguard/R8 configuration. Of course, it is better to test your code thoroughly, properly configure Proguard if you, let's say, load some classes only via reflection and so on. But reality sometimes strikes and bugs might go to production. In this case, the first thing that is needed is to find a bug and fix it. And only then have some retrospective to mitigate such situations in the future. When the bug is in production already every minute counts, therefore it is important to have some plan. Proguard configuration seems complex to someone who didn't work with it, so I recommend to take a look at its main features. Most of the time I'd say that issue is easy can be found and fixed by analyzing crash report logs. But sometimes the log is not that clear. In this article I'd like to introduce the plan to find what part of "Proguard" causing an issue, so you can debug more effectively. ## Security Issues of Cross Platform Tools DevFeed: [Security Issues of Cross Platform Tools]() Original publisher: [Read original article]() Author: Shai Almog Published: 2020-08-06T00:00:00Z Content type: opinion Language: en Sources: [CodeName One]() Topics: [Security](), [cross-platform](), [Reverse Engineering](), [obfuscation](), [Tool]() Tags: [cross-platform](), [obfuscation](), [reverse-engineering](), [security](), [tools]() ### AI overview The article examines security risks in cross-platform development tools. It explains that security varies by tool and support for features such as certificate pinning and encrypted storage, while readable or weakly obfuscated application code can enable repackaging and theft. It compares the reverse-engineering exposure of native GUI, web-based, and lightweight tools, and discusses obfuscation as a defensive measure. ### Source excerpt A couple of weeks ago I answered a question on Quora about the security of cross platform tools. I try to rise above my confirmation bias when discussing these things. I won't discuss Codename One in this context or any other specific tool. Only general ideas. Security depends a lot on the tools involved and their level of support for security features such as certificate pinning, storage/db encryption etc. Some tools also store the code of the app as plain text or obfuscated scripting code which is still fully readable, this can have a serious impact on security. ## Understanding the Android Build Pipeline with ProGuard and R8 DevFeed: [Understanding the Android Build Pipeline with ProGuard and R8]() Original publisher: [Read original article]() Author: dustin@dustn.dev (Dustin Summers) Published: 2019-11-06T12:08:40Z Content type: tutorial Language: en Sources: [Dustin Summers]() Topics: [R8](), [Code](), [obfuscation](), [software-development](), [Software]() Tags: [android](), [compilation](), [obfuscation](), [proguard](), [proguard-android-r8-smali-dalvik-jvm-kotlin-art-gradle-java](), [r8](), [software-development](), [tutorials]() ### AI overview A tutorial explaining the Android build pipeline and where ProGuard and R8 fit into it. It introduces compilation stages, optimization, shrinking, and code obfuscation, with an emphasis on understanding and diagnosing how these tools transform source code into bytecode. ### Source excerpt Tools such as R8 and ProGuard are available for free, but to many they are a black box that code goes into and stuff comes out. My goal is to demystify the black box and teach developers how to properly diagnose the code going into and coming out of these build tools. It will also explain why you should care and why applying these tools should be a priority before shipping any code into the wild. ## R8 Optimization: Class Reflection and Forced Inlining DevFeed: [R8 Optimization: Class Reflection and Forced Inlining]() Original publisher: [Read original article]() Published: 2019-09-25T00:00:00Z Content type: article Language: en Sources: [Jake Wharton]() Topics: [R8](), [Optimization](), [Android](), [obfuscation]() Tags: [android](), [code](), [inlining](), [obfuscation](), [optimization](), [r8]() ### AI overview This article explains how R8 optimizes Java class reflection in Android applications. It contrasts static class literals with instance getClass() calls, then describes how whole-program analysis can replace reflective calls with known class references and string constants. It also examines a case where method inlining is blocked by method-size limits and introduces forced inlining through R8 configuration rules compatible with ProGuard. ### Source excerpt Note: This post is part of a series on D8 and R8, Android's new dexer and optimizer, respectively. For an intro to D8 read "Android's Java 8 support". For an intro to R8 read "R8 Optimization: Staticization". The previous post on R8 covered method outlining which automatically de-duplicated code. This was actually a detour from what I had promised was next at the end of the class constant operations post which preceded it. So let's get back on track. Class constant operations allow R8 to take calls such as MyActivity.class.getSimpleName() and replace it with the string literal "MyActivity". This was presented in the context of log tags, where you might write that expression instead of the string literal so that the tag always reflects the actual class name, even after obfuscation. This works great in a static context where the MyActivity.class literal is fixed, but it does not work when used on an instance. Instance reflection When dealing with an instance, the Class reference is obtained by calling getClass() instead of a MyActivity.class literal. This operation is not terribly expensive, but it is still a form of reflection. class MyActivity extends Activity { @Override void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); String name = this.getClass().getSimpleName(); Log.e(name, "Hello!"); } } The getClass() API is just a normal method on every Object and appears as a normal invoke-virtual in bytecode. [0003d0] MyActivity.onCreate:(Landroid/os/Bundle;)V 0000: invoke-super {v1, v2}, Landroid/app/Activity;.onCreate:(Landroid/os/Bundle;)V 0003: invoke-virtual {v1}, Ljava/lang/Object;.getClass:()Ljava/lang/Class; 0006: move-result-object v2 0007: invoke-virtual {v2}, Ljava/lang/Class;.getSimpleName:()Ljava/lang/String; 000a: move-result-object v2 Since R8 is performing whole-program analysis, it knows that there are no subtypes of MyActivity even though it's not marked as final. As a result, it can replace calls to this.getClass() with MyAct ## TIP: Obfuscation Mapping File DevFeed: [TIP: Obfuscation Mapping File]() Original publisher: [Read original article]() Author: Shai Almog Published: 2018-10-15T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [obfuscation](), [Android](), [Google Play](), [toolchain](), [App]() Tags: [android](), [apk](), [apps](), [build](), [developers](), [development](), [google-play](), [mapping](), [obfuscation](), [programming](), [proguard](), [toolchain](), [tools]() ### AI overview This tutorial explains how ProGuard obfuscation affects Android stack traces and why the mapping file generated for each build is needed to interpret crashes and ANRs in Google Play. It advises uploading the mapping file that matches the submitted APK version. ### Source excerpt Proguard is one of the most disliked aspects of Android programming. Developers attack it left and right because there are so many nuances to it. That's a huge mistake, proguard is one of the most important tools in our development toolchain. It makes our apps slightly more secure, much smaller and even slightly faster. Codename One apps use proguard by default for Android. This is a huge benefit in our case because the limits related to obfuscation are very similar to the limits related to portability. ## Breaking ledgerctf's AES white-box challenge DevFeed: [Breaking ledgerctf's AES white-box challenge]() Original publisher: [Read original article]() Author: Axel "0vercl0k" Souchet Published: 2018-05-17T18:52:00Z Content type: article Language: en Sources: [Diary of a reverse-engineer]() Topics: [Cryptography](), [Encryption](), [Reverse Engineering](), [obfuscation](), [C++]() Tags: [aes](), [cryptography](), [encryption](), [ledgerctf](), [obfuscation](), [reverse-engineering](), [white-box](), [whitebox]() ### AI overview This article examines Ledger's ctf2 binary from its bug bounty puzzles, describing its AES white-box protection scheme and the author's reverse-engineering process for breaking it. The binary is presented as a C++ ELF64 executable with no apparent obfuscation, code encryption, or packing. ### Source excerpt Introduction About a month ago, my mate b0n0n was working on the ledgerctf puzzles and challenged me to have a look at the ctf2 binary. I eventually did and this blogpost discusses the protection scheme and how I broke it. Before diving in though, here is a bit of background ... ## Obfuscated Constants DevFeed: [Obfuscated Constants]() Original publisher: [Read original article]() Author: Shai Almog Published: 2017-02-14T00:00:00Z Content type: tutorial Language: en Sources: [CodeName One]() Topics: [obfuscation](), [Reverse Engineering](), [Security](), [App](), [JavaScript]() Tags: [app](), [javascript](), [obfuscation](), [reverse-engineering](), [security](), [xor]() ### AI overview The article explains how readable string constants can help reverse-engineer an application even when method names are obfuscated. It presents simple XOR-based string obfuscation methods and an accompanying browser-based encoder, while emphasizing that obfuscation is only a temporary obstacle and that critical secrets should be stored on a server. ### Source excerpt One of the first things a hacker will do when compromising an app is look at it. E.g. if I want to exploit a bank's login UI I would look at the label next to the login and then search for it in the decompiled code. So if the UI has the String "enter user name and password" I can search for that. It won't lead directly to a hack or exploit but it will show you the approximate area of the code where we should look and it makes the first step that much easier. Obfuscation helps as it removes descriptive method names but it can't hide the Strings we use in constants. So if an app has a secret encoding it even slightly can make a difference... ## Tweaking LLVM Obfuscator + quick look into some of LLVM internals DevFeed: [Tweaking LLVM Obfuscator + quick look into some of LLVM internals]() Original publisher: [Read original article]() Published: 2015-05-15T22:00:00Z Content type: tutorial Language: en Sources: [Dennis Yurichev]() Topics: [LLVM](), [obfuscation](), [Compiler](), [C++]() Tags: [c-plus-plus](), [compiler](), [internals](), [llvm](), [obfuscation]() ### AI overview An experiment extends LLVM Obfuscator with a transformation that replaces XOR with an equivalent expression using bitwise AND, multiplication, addition, and subtraction. The article also explains LLVM's internal Value and BinaryOperator object structure. ### Source excerpt Tweaking LLVM Obfuscator + quick look into some of LLVM internals ## Breaking Kryptonite's obfuscation: a static analysis approach relying on symbolic execution DevFeed: [Breaking Kryptonite's obfuscation: a static analysis approach relying on symbolic execution]() Original publisher: [Read original article]() Author: Axel "0vercl0k" Souchet Published: 2013-09-16T18:47:00Z Content type: tutorial Language: en Sources: [Diary of a reverse-engineer]() Topics: [obfuscation](), [execution](), [LLVM](), [clang](), [Assembly](), [x86](), [Code]() Tags: [analysis](), [asm](), [assembly](), [clang](), [code](), [llvm](), [obfuscation](), [reverse-engineering](), [static](), [symbolic-execution](), [x86]() ### AI overview This tutorial demonstrates how symbolic execution can break Kryptonite, a proof-of-concept obfuscator that applies semantics-preserving transformations at the LLVM intermediate representation level. It describes a small symbolic execution engine built with IDAPy and Z3Py, using an x86 binary generated from LLVM code for a 32-bit adder. ### Source excerpt Introduction Kryptonite was a proof-of-concept I built to obfuscate codes at the LLVM intermediate representation level. The idea was to use semantic-preserving transformations in order to not break the original program. One of the main idea was for example to build a home-made 32 bits adder to replace the add ... ## Regular expressions obfuscation under the microscope DevFeed: [Regular expressions obfuscation under the microscope]() Original publisher: [Read original article]() Author: Axel "0vercl0k" Souchet Published: 2013-08-24T19:35:00Z Content type: tutorial Language: en Sources: [Diary of a reverse-engineer]() Topics: [obfuscation](), [Finite-state machine](), [Regular expression](), [Reverse Engineering](), [Assembly](), [C]() Tags: [assembly](), [c](), [obfuscation](), [regex](), [regular-expressions](), [reverse-engineering]() ### AI overview This tutorial explains how regular expressions can be compiled into finite-state machines and represented directly in assembly or C, making them harder to analyze. It demonstrates a simple manual implementation and discusses recognizing and obfuscating compiled regexes during reverse-engineering work. ### Source excerpt Introduction Some months ago I came across a strange couple of functions that was kind of playing with a finite-state automaton to validate an input. At first glance, I didn't really notice it was in fact a regex being processed, that's exactly why I spent quite some time to understand ...