Intermediate names (Semi-deobfuscation) ​

What ​

Intermediate mappings are deobfuscation mappings that provides “intermediate” names rather than human-readable names.

Why ​

To explain why we need intermediate names, we need to trace the history of SRG, the first intermediate name system used in Modded Minecraft scene.

The concept of SRG names was invented by Searge. When MCP 1.4 was released, Searge wrote

Version 1.4 was just released.

The highlights of this release are:
[:wc8rjz32]Using a tool to make all field and method names unique
[:wc8rjz32]Fixed all known bugs of the recompiled game
[:wc8rjz32]Provided a file that can be used to rename classes, methods and fields
[:wc8rjz32]Much less decompile errors need to be fixed by patches, makes it more compatible with future updates

• Searge, at Oct 22nd, 2010 https://web.archive.org/web/20110713115004/http://www.minecraftforum.net/topic/54719-toolkit-minecraft-coder-pack/page__st__40

This was posted 5 days after the MCP release thread was created. MCP thread was created at Oct 17th, 2010.

Notice the “Using a tool to make all field and method names unique” part. This name is what we call SRG till today. It is still a mystry which tool Searge used, but it is most likely “Searge‘s RetroGuard”, as what LexManos names it.

A user raised the question on the rationale of this move on the second day:

Is there a good reason as to why you decided to rename all functions? Is it so you can put proper names on them later or what?

Either way, this breaks all other mods and is way more confusing than what we had in the original obfuscated code.

• Cadde, at Oct 23rd, 2010

Searge responded with

There are some reasons for this.
- This helps a lot to get it compiled without too much annoying errors and bugs.
- It makes it possible to reference a method or field uniquely. Just say "method 17" or "field 223" and everybody will know which one you meant.
- I want to use the "nicknames" from the google spreadsheet later to rename the classes.
- Last not least, I wanted to show an automated way to rename all classes, methods and fields.
- We need a way to update the decompiler later when new versions of minecraft (halloween) will be released. This tool can make this easier, all you need to know is the old class name and the new class name.
- There are much less patches needed to make the decompiled code re-compilable. For example the annoying if.class and do.class renames will be taken care of automatically.

This summerizes the design choice of SRG names. In short:

1. Give everything a unique identifier. Think about your ID number, SSN number, passport number, etc.
2. With the help of unique identifier, you can easily rename a thing, and automated tools will fix everything else in a blink.

Late, Searge posted another message:

In version 1.5 the naming convention for the de-obfuscator has changed. All renamed field will contain the original name in the new, unique name. So a field "f" will become "field_1234_f" and a method "int c(double)" will become "int func_4321_c(double)". This will make it easier to understand how the original names were before de-obfuscation.

• Searge, at Oct 23rd, 2010 https://web.archive.org/web/20110713115004/http://www.minecraftforum.net/topic/54719-toolkit-minecraft-coder-pack/page__st__40

In short, this is the origin of the _abc suffix of SRG names - they are the obfuscated names when they were firstly assigned a SRG name. It apparently served its initial purpose of “remembering the original name”, but as time goes by, this suffix eventually became obsolete and misleading.

SRG names historically have been func_####_obf or field_###_obf But the obf name is just the first time things have been encountered, and thus completely useless after a MC update. It gets into issues when people assume that this obf name means something, or that it can't change between MC versions.

LexManos, at Jun. 12th, 2020 https://github.com/MinecraftForge/MCPConfig/issues/85

This suffix was finally removed in the initial release of so-called “SRG v2” series.

How ​

Intermediate names are unique: two methods/fields with the same intermediate names MUST have same type descriptors, or MUST have covarient return types if they are methods and they have different return type, and thus being the same method/field, or override of the other.
They are immutable and never recycled: a class/method/field will permenantly occupy a certain name, regardless whether it is determined as "disappeared" in the future version. Some intermediate mapping system will attempt to match intermediate names between two versions to reduce porting workload on end-user (modder) side. They are the ID numbers of classes, fields and methods.

They are used to "hedge" the risk of binary incompatibilities from (often rapid) updates in human-readable names. By re-obfuscating a compiled mod to intermediate names, we can safely using whatever names in development time without breaking at runtime.

List ​

Special remarks: