sundance-communications.com/forum Forums TDM Business Telephone Systems Inter-Tel Telephones & Systems Suspect hacker changed IPRC password

One of my clients has an Intertel 5.2f system with IPRC, I believe version 1.5.2. (550.2265). We haven't used it in a while, but now would like to reconfigure it for some new phones. But, when I go to log into it, the password seems to have changed. We did not change the password, so I suspect that a hacker may have changed it for us!

Anyways, how does one factory default the card and/or reset the password back to default? Thanx in advance!

First thing is you use Session Manager to add and configure phones. The web interface of the IPRC is mainly for diagnostic and troubleshooting purposes. Sounds like you might be better off to contact an Intertel/Mitel dealer to gice you a hand if your not familiar with the system.

I'm very familiar with the system. On this version of the IPRC, all assignments of the phones to the device are done via the web page. The phone system sees the IPRC card as a standard DKSC-16 card. Session Manager is only used to control what each extension number does--it does not control how the phones connect to the IPRC.

We are running version 1.5.2 of the firmware. What you are referring to is version 7.x + of the firmware, where the phone switch is configured to maintain the card as an actual IPRC. (these versions also require endpoint licenses, which the 1.5.x versions do not).

On the 1.5.x versions, assigning MAC addresses to individual VOIP channels and all configuration of the various VOIP parameters are done via a password-protected web page. The issue is that somehow that password was changed (I suspect by a hacker) and we can not log into it.

UPDATE: I attempted to re-flash the card firmware to default the database. No luck. The reflash worked, but the database remained. I also tried flashing up/down between versions of the IPRC firmware, hoping I would configure a default of the database. Still no luck--the flashing worked, but the database and password remained. The database is stored in EEPROM, so there's no battery to remove.

I also hacked the actual IPRC firmware to look for undocumented commands. I found a few, but nothing that allows one to wipe out the database or password. There are commands to modify memory in the debugger on the card, which do not require a password, but one would have to know what memory locations contain the password to clear it.... I suspect that's how they do it when you send it back to the factory. Anyone have any more info?

Any ideas?

PM sent.

My bad, we get people in here all the time that are trying to work on stuff they know nothing about and shouldnt be working on. :nono:

Tito--trust me--I understand. I tend to charge extra to fix things that clients blow up because their "expert" (who also doubles as a secretary) screwed something up! People like that put food on my table....

Unfortunately, still no luck with this issue, though. I just pulled the card and was looking for an eeprom that might hold the config. (I'm also a hardware designer, so I could easily modify the contents of an onboard eeprom if necessary). Unfortunately, the only thing I found that was identifiable is the flash chip holding the bootloader and OS (don't wanna mess with that or I could brick the card). From what I gathered from the messages I deciphered in the firmware, wiping out even 1 byte of the configuration should be enough to trigger a default of the database (they do a checksum and if there is a problem, it defaults).

Now, to just figure out what memory location I need to change.....

(incidentally, they use a ColdFire CPU on the card, and if I remember correctly, it has a built-in eeprom, so I'd bet that's where the config is stored--nowhere near as easy to modify that, as compared to, let's say, a 93c46 chip)

FYI, if I do discover the "trick" I'll make the info available to those with a legitimate need who ask. (I'm assuming it'd be against the rules to post the solution publically, as that could enable a hacker to break into systems, right?)

Also, Stix, I can't reply to your PM for some reason, but it didn't work via the serial port either....