Blackberry - part II

[Alex Broens]

Hi Glenn,

On 8/6/2007 2:00 PM, Glenn Steen wrote:
> On 06/08/07, Alex Broens <ms-list at alexb.ch> wrote:
>> Guys
>>
>> Blackberry's ETP.DAT files are becomming a daily challenge:
>>
>> Today:
>>
>> ETP.DAT: SVR2 pure executable (Amdahl-UTS) not stripped - version
>> 1197568626
>>
>> Last Friday
>> ETP.DAT.old: mc68k executable (shared demand paged) not stripped
>>
>> a few weeks ago:
>>
>> ETP.DAT executable not stripped
>>
>>
>> anybody know someone at Blackberry?
>>
>> Can't imagine a company that size can't produce a consistent file header.
>>
>> or any better ideas?
>>
>> Thanks
>>
>> Alex
>>
> As I'm sure you've done, you can look at the message ... and see that
> it contains two parts:
> 1) the ETP.DAT in ascii armour
> 2) the pure binary file, containing the encrypted activation data.
> 
> If the idiots could code their system to only work with the prior, and
> dispensed entirely with the second... everything would be just dandy.

exactly - and do would expect to get a reply from their Support? YEAH RIGHT!

> As is, to be sure there is no problems activating a new handset,
> you'll have to do something like:
> - In /etc/MailScanner/rules/filetype.rules (referenced in the Filetype
> Rules setting in MailScanner.conf, of course):
> # Bloody ETP.DAT object files from blackberry...
> From:   *.blackberry.net
> %etc-dir%/filetype.whitelist.rules.conf
> (beware of linewrapping....:-)
> 
> - In /etc/MailScanner/filetype.whitelist.rules.conf .... basically
> just say "allow" to anything. You could make that a one-liner, or copy
> the normal filetypes rule file and change all the "deny" to "allow"

Using Mailwatch, I have "content.scanning.rules"

From:           127.0.0.1      no
FromOrTo:       default        yes


do you think it would make make more sense to add

From:           *.blackberry.net      no


to that? (and spare wathcing an extra rule file :-)

> There is no real way around this idiocy, since you cannot predetermine
> exactly which hosts (IP addresses/ranges) they might be sending from,
> nor determine exactly which file magics it can happen to match.

frustrating - just hard to believe nobody else has come across this 
before :-)

thanks

Alex