Blackberry - part II

[Glenn Steen]

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.
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"

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.

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se