My best interpretation of this question is that Java's crypto API has been subverted to perform RSA signature using PKCS#1 v1.5 encryption padding.
Assume the signature $S$ of a message $M$ is obtained by:
- hashing $M$ using SHA-1, yielding the 20-byte $H$;
- generating a 105-byte uniformly (true) random $R$;
- forming the 128-byte $P=\text{0x00}||\text{0x02}||R||\text{0x00}||H$;
- forming the 128-byte $S=P^d\bmod N$ where $(N,d)$ is a 1024-bit RSA private key.
I assume that verification of an alleged signature $S$ of alleged message $M$ is as follows:
- rejecting the signature unless $S$ is 128-byte with $S<N$;
- forming the 128-byte $P=S^e\bmod N$ where $(N,e)$ is the 1024-bit RSA publickey;
- hashing $M$ using SHA-1, yielding the 20-byte $H$;
- accepting the signature when the left 2 bytes of $P$ are $\text{0x00}||\text{0x02}$, and the 21th byte from the right of $P$ is $\text{0x00}$, and the right 20 bytes of $P$ are $H$.
Note: conversion from bytestring to number, and vice-versa, is per the big-endian convention.
What attacks are there on this scheme, easier than factoring the public modulus?