If I'm not totally mistaken and if the algorithm is really just aes_decrypt (sha256 (sha256 ($pass), $data) ... then your strategy to implement this kernel doesn't make much sense.
The main question that a dev always needs to ask himself before trying to implement a hashcat OpenCL kernel is: is it a slow or fast hash ?
Only (very) slow hashes need to have _init (), _loop () and _comp () kernel functions.
In my opinion the main problem in your attempt to implementation it is that you made the wrong first choice about how to implement this kernel (good thing is: it's actually easy to fix!). If it only uses 2 sha256 iterations (and one compare after the final aes decrypt step), it might be waaaaaayyy too fast to justify a slow-hash-kernel.
init/loop/comp are normally only used when there are a lot of iterations (in most cases even custom/arbitrary/flexible amounts of iterations). It seems that this is not true for this specific algorithm.
You could/should look into how to implement _a0, _a1 and _a3 kernel (which are used for the specific attack modes -a x). of course, you could start to implement only the kernel that you need urgently and afterwards implement the remaining kernels (e.g. if you want to use dictionary attack, you could implement the _a0 kernel first).
It's good that the implementation is actually very easy because it just needs a couple of copy-paste (since all the code blocks are already there within other kernels).
I'm not sure what you mean by these defines for the opencl compiler... we normally just set some variables within src/interface.c and therefore the host code let's the kernel know which defines are needed.... no additional/manual defines are needed in general.
I also think that it would make sense to open a github issue for this (for now: just to ask for support for this algorithm)... and maybe discuss the algorithm details and technical problems you experiencing while implementing it over there.
The main question that a dev always needs to ask himself before trying to implement a hashcat OpenCL kernel is: is it a slow or fast hash ?
Only (very) slow hashes need to have _init (), _loop () and _comp () kernel functions.
In my opinion the main problem in your attempt to implementation it is that you made the wrong first choice about how to implement this kernel (good thing is: it's actually easy to fix!). If it only uses 2 sha256 iterations (and one compare after the final aes decrypt step), it might be waaaaaayyy too fast to justify a slow-hash-kernel.
init/loop/comp are normally only used when there are a lot of iterations (in most cases even custom/arbitrary/flexible amounts of iterations). It seems that this is not true for this specific algorithm.
You could/should look into how to implement _a0, _a1 and _a3 kernel (which are used for the specific attack modes -a x). of course, you could start to implement only the kernel that you need urgently and afterwards implement the remaining kernels (e.g. if you want to use dictionary attack, you could implement the _a0 kernel first).
It's good that the implementation is actually very easy because it just needs a couple of copy-paste (since all the code blocks are already there within other kernels).
I'm not sure what you mean by these defines for the opencl compiler... we normally just set some variables within src/interface.c and therefore the host code let's the kernel know which defines are needed.... no additional/manual defines are needed in general.
I also think that it would make sense to open a github issue for this (for now: just to ask for support for this algorithm)... and maybe discuss the algorithm details and technical problems you experiencing while implementing it over there.