5

We have acquired a 4 channel GSM Gateway, model GoIPx4-G610 (the manual is titled "GoIP Series SIM Card for GSM Voice Gateway - GSM VOIP Gateway").

We are looking to develop a custom application to control the GOIP gateway. We have developed in the past custom applications that controlled simple GSM modems through AT commands for sending/receiving SMS messages in particular.

Although the gateway can be controlled through SIP we would like to control the GSM modems embedded in the gateway through AT commands if possible. This is because of the fine grained control AT commands offer and because we do not need VoIP features since we need only to send/receive SMS messages.

The gateway runs an unknown Linux instance to which we can connect through telnet. Unfortunately we do not have the credentials to authenticate to it. The gateway also has a web http administration interface to which we can authenticate but we can't find there settings/information related to channels that we can use for AT commands.

The documentation is very poor and the provider could not offer us any helpful information regarding this.

If anyone knows how we can send AT commands to the modems inside the gateway it is highly appreciated.

Up to now we have tried a brute force attack on the telnet interface to find the credentials with no success. We hope that once we can connect to the Linux instance driving the gateway we can connect from there to the modems through serial connections (to send AT commands) and we can reconfigure it to redirect the connections outside of the modem or to make an interface for sending commands to the modems.

The device has an update firmware option (through the web interface) which always gives the error "download failed". Downloaded the firmware (.pkg file) manually from their update pages and extracted the files from the embedded Linux distribution that should correspond to the ones placed on the gateway. The files were kept in the pkg file as an ROMFS compressed image which we mounted on a test station to see the files (probably the running OS on the gateway is an uClinux distribution).

Did this hoping that we can find there the /etc/passwd file which could be cracked with classic attack. However didn't found it and probably that file is placed on the gateway flash memory (contrary to the Linux files which are stored on the ROM memory). So if there is a way to erase / reset this flash memory that could be a solution (in case the gateway doesn't refuse to boot without those files). Another solution would be to be able to access the flash memory with the passwd file if there is such thing.

Alex P.
  • 1,140
  • 13
  • 27
  • Do you got it? I am also researching how to do this. – Alessandro Schneider Mar 27 '20 at 19:06
  • @AlessandroSchneider I haven't continued on that path, found alternative solution. I would've expected them to change their politics in the meantime but seems like some things never change. Check the comment about the backdoor, in the accepted answer. – Alex P. Apr 07 '20 at 19:41
  • Do your workaround with GoIP? Or are you using other hardware? I've already done something similar using USB Dongles, I'm researching something about GoIP. – Alessandro Schneider Apr 11 '20 at 12:04
  • @AlessandroSchneider I no longer work with GoIP (nor with other GSM gateways/hardware) and I am not updated with the advancements in the last years. – Alex P. Apr 14 '20 at 07:12

2 Answers2

3

You might take the lid off and see what parts are inside.

If it's a general purpose processor with a published data sheet and without a lot of code security features, you might be in luck. For example, you might find:

  • By guessing headers or tracing from known pins, a console serial port, either logic level or RS232, hopefully with a shell listening

  • A boot mode pin for the micro connected to a resistor, which you could jumper to cause the micro to boot to a uart bootloader where you could download a new system image, or patch the existing one. If you are lucky the bootloader would be something known, like u-boot.

  • A JTAG port for the processor

  • A removable storage device which you could remove and alter

  • an SPI flash which you could carefully tap into and alter

  • A flash chip which you could desolder and transplant to a programmer

You could also make a GPL sources request for the kernel and whatever else from the vendor. Or even just trying to identify versions of things like a web server could help you look up any known exploits. Since it seems you have a similar system image to that which is installed, looking through it could be helpful - look for additional daemons running, listening on ports you weren't previously aware of, left over debug support, etc.

Chris Stratton
  • 39,853
  • 6
  • 84
  • 117
  • Chris: thanks for your detailed answer (even if this late). Will accept your answer and post more details on one way we found to gain access to the gateway. – Alex P. Feb 19 '13 at 14:52
  • I have a newer version of the same model, can confirm a JTAG port (115200 baud) that leads to an U-Boot shell you can poke around in. Mine is bricked so not sure what happens after boot. Also someone found a backdoor telnet user for pre-2017-ish firmwares: https://www.trustwave.com/en-us/resources/security-resources/security-advisories/?fid=18750 – toster-cx Feb 19 '20 at 20:12
  • @toaster-cx You seem to be mislabelling a 115200 baud **asynchronous** serial interface as JTAG; JTAG is a **synchronous** interface. – Chris Stratton Feb 20 '20 at 06:17
0

I am the developer of the GoIP you've purchased. Instead of trying to hack the GoIP, did you contact us to support your development of custom applications? Here are the updates of GoIP for you.

  1. GoIP now supports SMPP. This could be an alternative to using AT commands to send and receive SMS.

  2. API (Application Programming Interface) for GoIP is now available to support your custom application development.

If AT commands are still the preferred method, please contact us and I would be happy to discuss with you further.

Charley
  • 1
  • thanks for your reply. How can we contact you directly? Tried through DBLTek support but haven't received a response. In response to your question: yes, we did contact DBLTek support in the past and they refused to allow us any access to the operating system running on the gateway (which by the way should be allowed by European rules where the product was shipped). Understand probably this is done to protect the custom OS distribution implementation and other information but think it was our right to try to hack the machine since we did it only for our purpose(with some success now). – Alex P. Feb 19 '13 at 14:47