V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
rv54ntjwfm3ug8
V2EX  ›  程序员

ASP.NET Core 存在类似 il2Cpp 这种可以把 C#代码转换成 C++代码编译来防止逆向获得原始代码的黑科技吗?如果不存在,为什么?

  •  
  •   rv54ntjwfm3ug8 · 2022-03-15 19:13:25 +08:00 · 2007 次点击
    这是一个创建于 766 天前的主题,其中的信息可能已经有所发展或是发生改变。
    现在大部分 Unity 游戏都用了 il2Cpp 保护 C#代码,虽然不能彻底防止逆向,但已经不可能通过逆向直接还原原本的 C#代码了。发现 ASP.NET Core 似乎不存在这样的黑科技工具,有 V 友知道为什么吗?
    14 条回复    2022-03-16 12:05:08 +08:00
    DTCPSS
        1
    DTCPSS  
       2022-03-15 19:21:58 +08:00   ❤️ 1
    .NET 7 会加入 Native AOT , 直接编译到机器码,现在预览版已经可以用在一些简单项目上。不过还有很多问题要解决,特别是对于 ASP.NET Core 这种重度依赖反射的框架。要完善还得过几个 release 吧。
    现在基本是 .NET 第一方 AOT 的断代期,连 WinUI 都没有 UWP 那样的 AOT 用。
    DTCPSS
        2
    DTCPSS  
       2022-03-15 19:24:49 +08:00
    这方面也许应该 @hez2010
    ch2
        3
    ch2  
       2022-03-15 19:45:35 +08:00
    后端的编译只是方便部署,产物压根不需要分发到用户手上,无从谈起防止逆向
    除非你是做 serverless 的,需要那么一两秒的冷启动耗时优化,不过这也只是 AOT 优化的副产物
    rv54ntjwfm3ug8
        4
    rv54ntjwfm3ug8  
    OP
       2022-03-15 19:50:18 +08:00
    @ch2 #3 有的时候会麦后端给客户自行部署,怕被修改后二次分发。
    rv54ntjwfm3ug8
        5
    rv54ntjwfm3ug8  
    OP
       2022-03-15 19:50:36 +08:00
    @theklf4 #4 typo: 麦=>卖
    jim9606
        6
    jim9606  
       2022-03-15 20:08:57 +08:00
    il2cpp 出生的目的不是防反编译,而是解决 Mono VM 不好跨平台移植而生的,增大反编译难度只是副作用。
    .NET 现在也有 AOT ,但能不能提供防反编译能力就不知道了,就像把 Java 编译成 JVM ByteCode 后反编译还是相对容易的。
    hez2010
        7
    hez2010  
       2022-03-15 23:15:46 +08:00   ❤️ 1
    .NET 7 会加入新的 NativeAOT 工具链,可以将应用程序像 C++、Rust 那样直接编译到本机代码,不含任何的 IL 代码,因此无法被反编译。不过首个版本应该会有不少兼容性问题,只能应对一部分代码。ASP.NET Core 可能还比较好办,但是 EF Core 这种重度依赖反射和表达式树的不一定能 works out-of-box 。
    forgottencoast
        8
    forgottencoast  
       2022-03-15 23:51:44 +08:00
    用混淆也差不多了吧,把所有可读性都去掉了,就算可以反编译出来的东西也很难读。
    如果框架再复杂一点,我觉得有能力把这样代码修改后二次分发的应该有本事自己开发一套。
    @theklf4
    gam2046
        9
    gam2046  
       2022-03-16 08:25:37 +08:00   ❤️ 1
    这个问题扩展一下,你会发现很多语言都不具备对抗破解的能力,从最近几年大热的 electron/.net core ,到老牌选手 Java/python 来看,几乎带有跨平台能力的开发语言被反编译都是接近源码级的。其中的例外选手也是有的,比如 Golang 是直接编译到 native code 。可人家直接编译到 native 的目的也并不是为了提高反编译难度,主要还是为了运行速度。

    同样再看看大厂应用,Microsoft 、Google 、Adobe 等企业出品的应用,几乎也没有在产品上做什么技术手段对抗反编译,基本上编译出来是啥就是啥。

    可以基本认为,语言的开发者(社区)以及多数开发人员都不太关心源码的保护。

    现在的对抗反编译的手法几乎是 10 年前没什么区别。

    1 、各种中间语言尽可能的编译成 native code
    2 、实在编译不成 native code 就加混淆,降低可读性
    3 、已经能编译成 native code 就再弄 OLLVM ,再混淆
    INCerry
        10
    INCerry  
       2022-03-16 10:29:21 +08:00
    1 、ASP.NET Core 上一般无需这种 AOT ,从数据来看,程序 AOT 以后性能会比 JIT 低,还需要损失很多提升工程效率的动态特性,总得来说是得不偿失。
    2 、客户端的话,AOT 有存在的价值,第一启动速度会提升,第二内存使用率会低一些,第三能具备一定的反编译能力(对于反汇编大佬来说,都是直接看汇编代码,无论你是 IL 、Native Code 还是啥,都没啥大的难度)
    3 、.NET 有 AOT 工具,如上面提到的 NativeAOT ,以及以前还有一个叫 NGen 的工具
    4 、那么 JIT 和 AOT 应该如何选择,主要看你的需求,这里有一张 Grralvm 的六边形图,说明了 AOT 和 JIT 的对比,看自己的项目类型来做取舍
    https://twitter.com/thomaswue/status/1145603781108928513
    INCerry
        11
    INCerry  
       2022-03-16 10:31:22 +08:00
    另外,我们项目中实测,.NET 这边就算是 JIT 的 Startup 速度也很快,基本都在 200~300ms ,不过 AOT 能让它更快。
    beyondex
        12
    beyondex  
       2022-03-16 11:57:32 +08:00
    有好几款三方工具,保护效果还可以。官方的是 AOT ,不过上面说了 AOT 本身的目的不是混淆。
    beyondex
        13
    beyondex  
       2022-03-16 11:59:36 +08:00
    漏了一个前提,三方工具只是用各种手段混淆代码,打乱指令,加密,并不是转成 native 。
    ragnaroks
        14
    ragnaroks  
       2022-03-16 12:05:08 +08:00
    有社区做的 neutral 工具,实际上效果不太好,除了反射,很多命名空间都不能用,但是倒是可以额外裁剪
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2796 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 14:00 · PVG 22:00 · LAX 07:00 · JFK 10:00
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.