Reverse Engineering

 

 Bricking an e-cigarette

June 17, 2009

I’m impressed. Rossi a colleague of mine,  has managed to “brick” his recently acquired e-cigarette. There was this “magic blue smoke smell” in the office, and we were all skulking around trying to figure out where the smell came from until we saw him grinning at his table.

Apparently the bricking had to do with the multimeter he held in his hands and “measuring something” and “getting the vapourizer a bit wet”.

Hehe. I’m kinda impressed tho. Everyone knows any new electronic device needs to be “hacked” and prodded a bit.

Hardware, Reality Reversing, Reverse Engineering, Uncategorized | 1 comment
1 response to “Bricking an e-cigarette”
  1. Kevin says:

    LOL 🙂 I was there!


Tags: , ,


 

 Accessing the internals of an iBurst UTD

December 27, 2007

I would have put a disclaimer here. But if you break your iBurst modem you have only yourself to blame, so no disclaimer. This was posted on the MyADSL forums, and people wanted to keep it secret, for fear of dimwits breaking their modems. Realistically, what difference is it going to make?

It is possible to telnet into you iBurst UT-D. Its quite simple:

* Connect UT-D via ethernet cable
* Set your ethernet connections’ IP to 192.168.250.5
You can also do this by simply adding an additional IP under the “Advanced Tab” under TCP/IP properties, if you don’t feel like changing your main IP.
* Open a command prompt (Start->Run->cmd.exe) Then type:

telnet 192.168.250.10 1234

If everything went well you should see a prompt from the UTD. If your networking is *incorrectly* configured, you will see a message saying “Connecting To 192.168.250.10… and it will appear to freeze there. Check everything again, if that’s the case.

!At the UTD prompt:
* Type “rfScan debug 2”, without the quotes. Hit enter.
* You will be presented with the base station # and the signal strength in dB and the distance and load of the BS.
* Once you are done type “rfScan debug 0”
* Kill the telnet session.

You should technically just be able to reboot the UTD too, to disable the debug mode.

Reverse Engineering | Leave a comment
Tags: , ,


 

 DefenseTurret – A Tribes2 Anti-Cheat by TheRoDent

December 26, 2007

Well, Tribes2 ended up being pretty cheat-free, but eventually some people came out with some really bad exploits.

DefenseTurret is my project to kerb these cheats. The program uses an executable injection mechanism to seamlessly load into the tribes2.exe Win32 and tribes Linux binaries.

The basis of the system is a “consensus based” cheat detection mechanisms where clients connected to the server check the validity of each others’ playing environments.

It’s been accepted on the European, and American ladders as the de-facto (read ONLY) anticheat program for Tribes2. I released a Win32, and Linux version.

More information can be found at http://rodent.za.net/defenseturret/, or http://dt.triben.de/dt_en.html

Game Development, Reverse Engineering | Leave a comment
Tags: , , , , ,


 

 How to get a VOX Phone not to use ADSL

So, recently Vox Telecom released their Viral Marketing based Voice over IP service late this year.

Their standard VOIP phone is a nifty device, based on the Thomson SpeedTouch 7G device, incorporating a DECT Phone, Wireless Router (Broadcom based) and also an ADSL modem.

My problem is – I have a neat Linux-based ADSL setup already, and didn’t really want to use the VOX phone as my ADSL to Ethernet Bridge (I have my reasons).

After some reverse engineering, it turns out, that using the CLI interface of the router, it can be convinced to not use it’s own ADSL connection as the upstream towards the VOX sip service. Instead it can be forced to use the “LAN” ethernet ports and by simply doing a bit of route adding, and forcing the voice service to use the LAN interface, the phone can happily work with Vox’s service across some other internet gateway.

Caveat Emptor: Of course, you have to be sure that your Internet gateway supports the proper QoS, otherwise the VOX service will suffer. And please, don’t call VOX’s support if you’re having problems with this kinda config. It is (and rightfully so) an unsupported configuration.

You will need to do all the NAT Traversal bits, and cleverness for this to work too, which is beyond the capability of your regular user – so, again. Consider it “unsupported”.

That said it still works…

Here’s the configuration

ip ipadd intf=LocalNetwork addr=192.168.0.201
ip rtadd dst=0.0.0.0 gateway=192.168.0.1 intf=LocalNetwork
dns client dnsadd addr=192.168.0.1
dns server config WANDownSpoofing=disabled
dns server route add dns=192.168.0.1 intf=LocalNetwork
voice config intf=LocalNetwork
system config defaultconnection=LocalNetwork
config save filename=user

Reverse Engineering | 1 comment
1 response to “How to get a VOX Phone not to use ADSL”
  1. Gordon says:

    Hi Roelf,

    I tried this config and can get the vox router to go via my laptop which provides the PPPOE connection for my iBurst, for just internet only! no telephony. The vox router won’t register the phone no. no firewalls on etc.

    any ideas??


Tags: , , ,