@TOC

sign and data algorithm of a residential meeting

According to packet capturing analysis, there are three parameters in the app request of huazhuhui, namely sign, data and time. Time is the current time, accurate to seconds. Sign and data are base64 encoded after a series of operations.

Capture analysis

It can be seen from the figure that both the request and the response are not clear text. From the content type application / octet stream in the response header, the response message can be seen to be in the form of byte stream, switching to hexadecimal mode.

Decompile

Here we open it with jeb, export the source code, and open it with idea

Find data and sign processing logic

Through search and analysis, we know that the code to calculate data is

public class NewGetString {
    static {
        System.loadLibrary("hzsign");
    }

    public static String a(String arg2, String arg3) {
        Class v0 = NewGetString.class;
        __monitor_enter(v0);
        try {
            arg2 = NewGetString.getNewStr(arg2, arg3).replaceAll("\r\n", "");
        }
        catch(Throwable v2) {
            __monitor_exit(v0);
            throw v2;
        }

        __monitor_exit(v0);
        return arg2;
    }

    private static native String getNewStr(String arg0, String arg1) {
    }
}

It's a local method. By name, we enter the lib/armeabi directory and find libhzsign.so. Later, we open it with IDA for analysis.

Next, look for the calculation location of sign.

v0.a("sign", Base64.encodeToString(ab.c(v1.toString()), 2));

The c method of entering the class ab

public static byte[] c(String arg2) {
        MessageDigest v0;
        try {
            v0 = MessageDigest.getInstance("MD5");
            v0.reset();
            v0.update(arg2.getBytes("UTF-8"));
            goto label_10;
        }
        catch(UnsupportedEncodingException ) {
        label_10:
            return v0.digest();
        }
        catch(NoSuchAlgorithmException ) {
            System.exit(-1);
            goto label_10;
        }
    }

This is an md5 algorithm.

Reverse libhzsign.so

The function of instruction set is not interpreted one by one.

Reduction algorithm

public static String deData(String data) {
        return EncodingUtils.decodeToString(Base64.decodeBase64(data), KEY);
    }
public static String getSign(String unSignData, String time) {
        ...
        return Base64.encodeBase64String(DigestUtils.md5(unSign));
    }
public static String getData(String unSignData) {
        return Base64.encodeBase64String(EncodingUtils.encode(unSignData.getBytes(), KEY));
    }
public static String deResponse(byte[] responseData) throws IOException {
        ...
    }

Verify the correctness of the algorithm

After decrypting and encrypting the data obtained from the packet capture, it is completely consistent with the original packet, and true has been printed out in the console.
The sign value is also consistent with the sign in the packet capture.

If you are interested in Android reverse, you can join the group: 912146030 to communicate and make progress together.