I've just got an external 56k modem manufated by atlantis and sold (at a really low price) by a free italian isp.
The problem is it's locked as you are not supposed to use it without the isp unlocking software it come with.
The unlocking procedure only consists in sending an 8 byte string to the modem.
If you give the wrong code more than 3 times the modem hangs untill switched off/on.
I've "guessed" the unlocking string in no time but now there's another problem:
the unlocking code needs to be send to the modem each time an application opens a handle to the modem (or to the com) port.
The question: how can i hook the modem, under win9x, so that i can unlock it before comunications? And under Linux?

Thanks,
aCaB

I think the RasDial function may be what you are looking for. I've never used any of the RAS functions thus far but from examining the net detect agent with ICQ these seem to be the relevant functions to do with connections on windows.

Help references are:

Attacking Windows 9x with Loadable Kernel Modules
by Solar Eclipse

and:
http://www.sysinternals.com

Regards,
TOTEU

Thanks a lot for your help, I was already aware of this solution 'cause I used portmon to "guess" the unlocking code, but at the moment I know too little about vxd's to write one myself.
What I'm trying is a similar approach: api hooking using a little piece of code made available to all processes through a memory mapped file.
But now the further question is: how can applications open the modem?
The only two ways I know, under win9x, are "CreateFile" and "opencomm". Are there other api's I need to hook?
The other problem is that this attack is useless if the modem is driven by a dos program through in and out instructions, but that's not too important.

aCaB

> I've "guessed" the unlocking string in no time but now
> there's another problem : the unlocking code needs to be
> send to the modem each time an application opens a handle
> to the modem (or to the com) port.

The modem has no clue which application your request is coming
from, which would mean that another AT sequence is sent to lock
the modem each time a new application is started. Disassemble
your driver and/or use PortMon, and look for suspicious AT strings.

> What I'm trying is a similar approach: api hooking using a little
> piece of code made available to all processes through a
> memory mapped file.

That may work, but it is not a good idea because the driver's code
will always be called after yours ; you would have better chances
by running your code at driver's level or below.

Btw, I find the board ugly but the contents are
so far much more interesting than before.

Spath.

Thanks a lot Spath,
here's little explanation.

"The modem has no clue which application your request is coming
from, which would mean that another AT sequence is sent to lock
the modem each time a new application is started. Disassemble
your driver and/or use PortMon, and look for suspicious AT strings."

Well... nothing at all.
The modem driver is just the standard "unimodem.vxd" taken from win9x cdrom.
The lock is simplier: when any application open the modem (i.e. "Call CreateFile,'COM2',..." or "opencom, 'COM2',..." the modem waits for the unlocking code.
If the code is good it is ready to receive commands (AT...).
But, when the handle to the modem is closed (i.e. "Call CloseHandle, [modem_handle]" or closecomm,[modem_handle]) il locks again.
It would be nice to open and unlock it just once, but serial-device handles, as long as i know, are not shareable between processes under windows.

So, the approach i've choosed (i'm almost finished with it) is to hook CreateFile and opencomm.
The hook proc:
- verifies if the device to open is actually the locked modem
- calls CreateFile (or opencomm) to get the handle
- sets up the com port (speeds and timeouts)
- sends the unlocking string (via WriteFile or writecomm)
- receives the confirmation message
- restores default speeds and timeouts (not really important)
- returns to calling process


Any hints for a workaround under Linux?

aCaB

> The lock is simplier: when any application open the modem
> (i.e. "Call CreateFile,'COM2',..." or "opencom, 'COM2',..."
> the modem waits for the unlocking code.

No, because the modem cannot know if the traffic is coming
from a new or an already existing program, it is just receiving
raw commands and raw datas from a COM port. This means that
this lock must come from some specific piece of code installed
on your system ; check your installation logs for a new driver,
a DLL replacement, etc. Then if you can find where and how this
locking is done, and remove it. Please drop me a mail if you make
progress, this is interesting.

Regards,

Spath.

Sorry Spath, but this is the situation.
No specific drivers, no hidden unlockers.
To be sure i've made a little experiment on a clean machine with nothing on it but a fresh windows installation.
I've opened Hyper Terminal, made a connection directly to com3 (port to which the modem is connected).

Sent: AT
Received: Password error !!

Sent: ******** (the unlocking code)
Recv: Password check ok......

Sent: AT
Recv: OK

Sent: ATZ
Recv: OK

At this time i've clicked on the 'Disconnect' button and then on the 'Connect' button.
Sent: AT
Received: Password error !!

Sent: ******** (the unlocking code again)
Recv: Password check ok......

Sent: AT
Recv: OK


I think that this is the proof that the modem unlocks itself after receiving the rigth password and locks by itself.

aCaB

you may want to check out the .inf files that came with your modem, or the modem related registry keys where some of the info in .inf ends up. i forget the precise path in the registry, but you can do a search for 'init' or 'modem' and you'll see what windows will send to your modem on init (this also explains why no extra driver trickery is needed).

> To be sure i've made a little experiment on a clean machine

Very good test, thanks. I assume you just plugged the modem on
a machine where it has never been installed before ; if not then
you should also check Owl's suggestion (even if I seriously doubt
that an INIT string can cause the modem to lock itself back
from times to times).

> I think that this is the proof that the modem unlocks itself
> after receiving the rigth password and

Yes, I never discussed this.

> locks by itself.

Well, not really. When you click on "disconnect", this call
CloseComm() down to _VCOMM_CloseComm, which performs a 10 bytes
handshake with the modem (especially with MCR/LCR registers).
Now all this handshake is not strictly required from the
modem's point of view if another application is still using
the line ; however, it seems the modem use it to decide when
to lock itself back. Basically I think these guys did not
need to add their own locking command because MS gave them
already a nice sequence to detect (home made tools would
not make it lock itself back).

So from here, the best choice is in my opinion the one you
took, that is replacing OpenComm() by OpenComm()+WriteComm(unlockcode).

Regards,
Spath.

To The Owl: this was the first attack I tried after discovering the onlocking code, but i've found out that the init string is ignored by almost any application and by windows itself.

To Spath: "Basically I think these guys did not
need to add their own locking command because MS gave them already a nice sequence to detect..."
Sorry, i think there was a little misunderstanding: i agree that this must be the key.

In my solution i hooked CreateFileA ('cause opencomm isn't used by dialup nor by the fax application i'm using).

Thanks everybody,
acab

I'm also interesed in a linux and a hardware (i'm thinking about using a pic 12cxxx) workaround. Any suggestion?