Decompiling

decompilers (fail to) work as such: find which architecture -> disassemble -> pattern finder/search for common code segments/idioms, language dependent -> turn into higher level code. it would seem to me what is needed is a good database of the high-level -> assembly idioms, that the decompiler accesses at run time and is always updated as new links are found (thinking that the decompiler would be part of a suite with other tools to help find these links). how many different ways do different compilers really have available to make "if(a==b)"? and more complex code is just combination of these smaller parts. assuming they optimize when compiling, that's what's really needed, a way to keeping track of these different ways of doing the same thing, slight variations, etc., and of course a way to find them in the first place (the suite i mentioned, which i also have ideas for; properly formatted assembly for starters). i don't get why decompilers don't work.

>>17
If you insist on trolling, at least use sage.
 
Changing the channel and turning off SSID broadcasting will accomblish nothing.
 
Changing the DHCP could confuse an intruder a bit but it would require changing the DHCP config file on the router and I'm sure you can't do that with the normal tools on most routers. Also you'd need to change the router's subnet and IP so that the intruder can't find it just from remembering the old IP. And you need to remember not accidentally using the DHCP yourself. All in all, too much effort for too little gain in security.
 
If you want real security, put the router in a DMZ and use some kind of SecurID/VPN/proxy authentication.