Hi Sylvain, thanks for your status update. I would be interested in playing with your IDA work, but I'm currently really on holidays and try to stay away from getting involved in even more aspects of the project. So I'll check your currenv version in mid-April... With regard to patches: I thought there were some non-context variants of diff. In that case, even a diff does not include original code before you patched it. Those diffs are very flaky to apply and don't work if you have any local modifications, of course. But assuming everyone got the same source to the plugin in the IDA SDK, it should work. Also, as dieter has indicated, he knows Hexrays well and I think it should be no problem to get your modifications merged in the next IDA release and/or published somewhere on their website. Regards, Harald -- - Harald Welte <laforge(a)gnumonks.org> http://laforge.gnumonks.org/ ============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)

Hi everyone, So, here we are, 8 days laters, I tought a small update would. Now that my IDA works nicely with the code. I started really digging into what it does. * First, the code makes heavy use of jump tables and indirect call. Most of the init is to copy function pointers (or a few times, function themselves) from the ROM to the RAM and then use them from RAM. This kinda screws with the autoanalysis of IDA and I'll have to write a script to handle that gracefully. That also means that you can override those jump tables with whatever you want. After the init is done, the DSP will jump to the address set in d_grps_install_address. Currently we point this one to 0x7002 which is just a 'ret' instruction but we could put in the API ram a custom function that hooks whatever we need. * Second, I found the main demodulation routines : - prom0:7c27 -> Normal burst decoding : This starts with 190 IQ samples (16bits I, 16bits Q) at the start and finishes with 114 bits + 2 stealing bits at the end of the array. At the output they are not hard bits but still 'semi-soft bits', that is it's a 4 bits signed value between -8 -> 7, even after deciphering. I think they keep them soft so that when applying the error correction they can take advantage of that information somehow. (that's unverified for now tough) - prom0:7c2c -> SCH burst decoding : This starts with 190 IQ samples as well and finishes with 78 softbits. I haven't dug much into this one yet, but the final memcpy of 78 values makes me think this is SCH :) It's also interesting to note that the raw IQ values should still be in the API zone after demodulation :) * Third, when looking at the code, it sometimes look like a mess ... there is no calling convention that I can see, every function seem to have it's own way of making. There is also very little stack usage for temporary variables, they seem to use global variables for that and the same variable can be re-used somewhere else with a completely different meaning ... I'll continue digging in the demodulation stuff to see how they do the demod exactly. It's my experience that they're much better at it than airprobe is and I want to find out what tricks they have up their sleeves :) I'll probably also have a look at the TX side, see if I can hook something to TX FCCH/SCH frames somehow ... Cheers, Sylvain