AES Encryption in Java to match with C# Output

I am trying to do AES Encryption using JAVA, I have made multiple attempts, tried a lot of codes and did many changes to finally reach to a place where my encrypted text matches with the encrypted text generated using C# code BUT PARTIALLY. The last block of 32 bits is different. I do not have access to the C# code since it is a 3rd Party Service. Can anyone guide what am I missing?

Conditions Mentioned are to use:

Use 256-bit AES encryption in CBC mode and with PKCS5 padding to encrypt the entire query string using your primary key and initialization vector. (Do not include a message digest in the query string.) The primary key is a 64-digit hexadecimal string and the initialization vector is a 32-digit hexadecimal string.

The sample values I used are:

Aes_IV = 50B666AADBAEDC14C3401E82CD6696D4

Aes_Key = D4612601EDAF9B0852FC0641DC2F273E0F2B9D6E85EBF3833764BF80E09DD89F (my KeyMaterial)

Plain_Text = ss=brock&pw=123456&ts=20190304234431 (input)

Encrypted_Text = 7643C7B400B9A6A2AD0FCFC40AC1B11E51A038A32C84E5560D92C0C49B3B7E0 A072AF44AADB62FA66F047EACA5C6A018 (output)

My Output = 7643C7B400B9A6A2AD0FCFC40AC1B11E51A038A32C84E5560D92C0C49B3B7E0 A38E71E5C846BAA6C31F996AB05AFD089

public static String encrypt( String keyMaterial, String unencryptedString, String ivString ) {
    String encryptedString = "";
    Cipher cipher;
    try {
        byte[] secretKey = hexStrToByteArray( keyMaterial );
        SecretKey key = new SecretKeySpec( secretKey, "AES" );
        cipher = Cipher.getInstance( "AES/CBC/PKCS5Padding" );
        IvParameterSpec iv;
        iv = new IvParameterSpec( hexStrToByteArray( ivString ) );
        cipher.init( Cipher.ENCRYPT_MODE, key, iv );
        byte[] plainText = unencryptedString.getBytes( "UTF-8") ;
        byte[] encryptedText = cipher.doFinal( plainText );
        encryptedString = URLEncoder.encode(byteArrayToHexString( encryptedText ),"UTF-8");
    }
    catch( InvalidKeyException | InvalidAlgorithmParameterException | UnsupportedEncodingException | IllegalBlockSizeException | BadPaddingException | NoSuchAlgorithmException | NoSuchPaddingException e ) {
        System.out.println( "Exception=" +e.toString() );
    }
    return encryptedString;
}

I have used this for conversions.

public static byte[] hexStrToByteArray ( String input) {
    if (input == null) return null;
    if (input.length() == 0) return new byte[0];

    if ((input.length() % 2) != 0)
        input = input + "0";

    byte[] result = new byte[input.length() / 2];
    for (int i = 0; i < result.length; i++) {
        String byteStr = input.substring(2*i, 2*i+2);
        result[i] = (byte) Integer.parseInt("0" + byteStr, 16);
    }
    return result;
}
public static String byteArrayToHexString(byte[] ba) {
    String build = "";
    for (int i = 0; i < ba.length; i++) {
        build += bytesToHexString(ba[i]);
    }
    return build;
}
    public static String bytesToHexString ( byte bt) {
    String hexStr ="0123456789ABCDEF";
    char ch[] = new char[2];
    int value = (int) bt;

    ch[0] = hexStr.charAt((value >> 4) & 0x000F);
    ch[1] = hexStr.charAt(value & 0x000F);

    String str = new String(ch);

    return str;
}

Any Suggestions, what should I do to match the outputs?

If only the last block of ECB / CBC padding is different then you can be pretty sure that a different block cipher padding is used. To validate which padding is used you can try (as Topaco did in the comments below the question) or you can decrypt the ciphertext without padding. For Java that would be "AES/CBC/NoPadding".

So if you do that given the key (and IV) then you will get the following output in hexadecimals:

73733D62726F636B2670773D3132333435362674733D3230313930333034323334343331000000000000000000000000

Clearly this is zero padding.

Zero padding has one big disadvantage: if your ciphertext ends with a byte valued zero then this byte may be seen as padding and stripped from the result. Generally this is not a problem for plaintext consisting of an ASCII or UTF-8 string, but it may be trickier for binary output. Of course, we'll assume here that the string doesn't use a null terminator that is expected to be present in the encrypted plaintext.

There is another, smaller disadvantage: if your plaintext is exactly the block size then zero padding is non-standard enough that there are two scenarios:

1. the padding is always applied and required to be removed, which means that if the plaintext size is exactly a number of times the block size that still a full block of padding is added (so for AES you'd have 1..16 zero valued bytes as padding);

2. the padding is only applied if strictly required, which means that no padding is applied if the plaintext size is exactly a number of times the block size (so for AES you'd have 0..15 zero valued bytes as padding).

So currently, for encryption, you might have to test which one is expected / accepted. E.g. Bouncy Castle - which is available for C# and Java - always (un)pads, while the horrid PHP / mcrypt library only pads where required.

You can always perform your own padding of course, and then use "NoPadding" for Java. Remember though that you never unpad more than 16 bytes.

General warning: encryption without authentication is unfit for transport mode security.