Refining Uncle Bob’s Clean Code(三)

本文详细介绍了 ArgumentMarshaler 接口的升级版,包括其新增的功能和使用方式。重点解析了 AbstractArgumentMarshaler 抽象类如何帮助实现更灵活的参数处理,并通过 DateArgumentMarshaler 的实例展示了具体的实现过程。

But now, let’s take a closer look at the new interface of ArgumentMarshaler:

01 public interface ArgumentMarshaler {
02  
03     public boolean canHandle( String schemaElement );
04  
05     public int getNumberOfArgs();
06  
07     public ArgumentMarshaler newInstanceFor( String schemaElement );
08  
09     public String getArgumentId();
10  
11     public void set( String...arguments ) throws ArgsException;
12  
13     public Object get();
14  
15 }

As you can see, an ArgumentMarshaler is now a little bit more powerful. As said, it can decide, wether or not a given schema element can be handled by a distinct Marshaler, it also ‘knows’ about the current argumentId it’s responsible for (so we can get rid of the set ‘argsFound‘, since we only have to ‘ask’ the current Set of Marshalers about the dedicated argumentIds. In addition to that, a Marshaler knows about the number of arguments he’s capable to process. As you will see, there might be some kind of Marshalers, that may take more than one argument for conversion (like for exampe a DateArgumentMarshaler, which will take three arguments – year, month and day).

One of the most important points – each Marshaler acts as a Factory for producing new instances of its own type. We surely could have separated those two responsibilities, but for this first refinement, i’ll leave it within the Marshaler (that’s kind of ugly, i know – but i want to leave some work for the next boy scouts ;o)).

Can you handle this ?

Let’s take a closer look on how a distinct ArgumentMarshaler decides, if he can handle a given schema element. For this feature, i extended the functionality a bit. In the origin example it was only possible to allow argumentIds that consist of a single letter. But there are surely some argumentIds that might be longer than a single character (like -classpath or -keystore).

I decided to use an abstract base class that will process the most part of the decision, leaving only the ‘details’ to the implementations:

01 import java.util.regex.Pattern;
02  
03 public abstract class AbstractArgumentMarshaler implements ArgumentMarshaler {
04  
05     private String argumentId = null;
06  
07     public AbstractArgumentMarshaler( String argumentId ){
08         this.argumentId = argumentId;
09     }
10  
11     @Override
12     public String getArgumentId() {
13         return argumentId;
14     }
15  
16     public abstract Pattern getArgumentIdPattern();
17  
18     public abstract String getArgumentTypePostfix();
19  
20     public abstract ArgumentMarshaler newInstance( String argumentId );
21  
22     public boolean canHandle( String element ){
23  
24         if( element.length() < getArgumentTypePostfix().length() ){
25             return false;
26         }
27  
28         String argumentId = removeArgumentTypePostfixFrom( element );
29  
30         return
31             element.endsWith( getArgumentTypePostfix() ) &&
32             consistsAtLeastOfOneCharacter( argumentId ) &&
33             matches( argumentId, getArgumentIdPattern() );
34     }
35  
36     public ArgumentMarshaler newInstanceFor( String schemaElement ){
37         return newInstance( removeArgumentTypePostfixFrom( schemaElement ) );
38     }
39  
40     private boolean consistsAtLeastOfOneCharacter( String argumentId ){
41         return argumentId != null && argumentId.length() > 0;
42     }
43  
44     private boolean matches( String argumentId, Pattern regexp ){
45         return regexp.matcher( argumentId ).matches();
46     }
47  
48     private String removeArgumentTypePostfixFrom( String element ){
49         return element.substring( 0, ( element.length() - getArgumentTypePostfix().length() ) );
50     }
51 }

As you might see, AbstractArgumentMarshaler puts some burden on its subclasses (the mentioned details). It needs to know the argumentTypePostfix (like ‘*’) and the so called argumentIdPattern – a regexp pattern, constraining the possible instantiations of allowed argumentIds. To be compatible with the origin behaviour, we would only allow a single character argumentId ( ‘[a-z]‘).

… yes, I can handle this !

When inheriting from AbstractArgumentMarshaler, there’s again not too much more left to do than fulfilling the claimed template methods and processing the passed arguments. Let’s look at some concrete ArgumentMarshaler:

01 import java.util.Calendar;
02 import java.util.Date;
03 import java.util.regex.Pattern;
04  
05 import com.mgi.util.args.ArgsException.ErrorCode;
06  
07 public class DateArgumentMarshaler extends AbstractArgumentMarshaler {
08  
09     private static final Pattern ARGUMENT_ID_PATTERN = Pattern.compile( "([a-z]|[A-Z])*" );
10     private static final String ARGUMENT_TYPE_POSTFIX = "<date>";
11  
12     private Date date = null;
13  
14     public DateArgumentMarshaler( String argumentId ) {
15         super(argumentId);
16     }
17  
18     public DateArgumentMarshaler(){
19         thisnull );
20     }
21  
22     @Override
23     public ArgumentMarshaler newInstance(String argumentId) {
24         return new DateArgumentMarshaler( argumentId );
25     }
26  
27     @Override
28     public Pattern getArgumentIdPattern() {
29         return ARGUMENT_ID_PATTERN;
30     }
31  
32     @Override
33     public String getArgumentTypePostfix() {
34         return ARGUMENT_TYPE_POSTFIX;
35     }
36  
37     @Override
38     public int getNumberOfArgs() {
39         return 3;
40     }
41  
42     @Override
43     public void set(String... arguments) throws ArgsException {
44  
45         assertValid( arguments );
46  
47         try{
48             Calendar calendar = Calendar.getInstance();
49             calendar.set( Calendar.DATE, Integer.parseInt( arguments[0] ) );
50             calendar.set( Calendar.MONTH, Integer.parseInt( arguments[1] ) - 1 );
51             calendar.set( Calendar.YEAR, Integer.parseInt( arguments[2] ) );
52             calendar.set( Calendar.MINUTE, 0 );
53             calendar.set( Calendar.SECOND, 0 );
54             calendar.set( Calendar.MILLISECOND, 0 );
55  
56             this.date = calendar.getTime();
57         }
58         catch (NumberFormatException e) {
59             throw new ArgsException( ErrorCode.INVALID_DATE_ELEMENT, getArgumentId(), arguments[0] );
60         }
61     }
62  
63     private void assertValid( String... arguments ) throws ArgsException {
64  
65         if( arguments[0] == null ||
66             arguments[1] == null ||
67             arguments[2] == null ){
68  
69             throw new ArgsException( ErrorCode.MISSING_DATE_ELEMENT, getArgumentId(), null );
70         }
71     }
72  
73     @Override
74     public Object get() {
75         return date;
76     }
77 }

内容概要:本文详细记录了对一个Android ARM64静态ELF文件中字符串加密机制的逆向分析过程。该ELF文件的所有字符串均被加密,无法通过常规strings命令或IDA直接识别。作者通过分析发现,加密字符串存储在.rodata段,其解密所需信息(包括密文地址、长度和16位密钥)保存在.data.rel.ro段的40字节描述符中。核心解密函数sub_10F408采用自反的双pass流密码算法,结合固定密钥KEY_TERM(由.data段24字节数据计算得出),实现字节级非线性、位置与长度相关的加密。文章还复现了完整的Python解密脚本,并揭示了该保护机制的本质为代码混淆而非强加密,最终成功批量解密全部956条字符串,暴露程序真实行为,如shell命令模板、设备标识篡改、网络重置等操作。此外,文中还提及未启用的自定义壳框架及其反dump设计。; 适合人群:具备逆向工程基础的安全研究人员、二进制分析人员及对ELF保护技术感兴趣的开发者。; 使用场景及目标:①学习ELF二进制中字符串加密的典型实现方式与逆向突破口;②掌握从结构识别、函数追踪到算法还原的完整逆向流程;③理解“绑定二进制”的完整性校验设计及其局限性;④实践编写IDAPython脚本自动化提取与解密敏感数据。; 阅读建议:此资源以实战案例驱动,不仅展示技术细节,更强调逆向思维与验证方法,建议读者结合IDA调试环境,逐步跟随文中步骤进行动态分析与算法验证,深入理解每一步的推理依据。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值