4 ms·

> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. There is still some information lost in the process:

by umvi 6y ago

> Assume for every code obfuscator there's a deobfuscator or at least someone as clever as you out there. There is still some information lost in the process: - "let eigenvector_coefficient = 23" => "let x = 23" A de-obfuscator isn't going to be able to recover the valuable information contained in the original name. Will it stop a determined attacker? Maybe not, but it would surely slow them down as they now need to spend an order of magnitude longer trying to understand what the code is doing. > Randomizing variable names it just a nuisance, it won't stop any competent pen tester or attacker. Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit. Remember, the goal is to "reduce risk" and not "stop any highly skilled targeted/tailored attack". Because let's face it, even if you are the greatest crypto wizard in the world, you will fall victim to a highly sophisticated attack tailored specifically to you.

aeternum 6y ago
It might make sense in some contexts, but code obfuscation is a great example of where software engineers think it provides security where it provides none. Developers often have some idealized notion that an attacker is going to need to piece their program logic back together and try to decode the purpose of each obfuscated variable in order to find a hardcoded password/value. In reality an attacker is just going to dump strings and try them all or simply set a breakpoint just before the important syscall and let your program do the work. Code obfuscation provides little to no value for these common methods, yet we cannot resist the urge to list it as a bullet point in security meetings, leading to a false sense of security.
- saagarjha 6y ago
  Exactly. If you're running crypto and think getting rid of variable names is going to stop people; it's not. Any off-the-shelf algorithm is usually easy to recognize to an accomplished reverse engineer with a basic background of what kind of things they're looking for.
  - XMPPwocky 6y ago
    Honestly, the modern JavaScript toolchain is better at giving reverse engineers a headache than 80% of binary obfuscators.
    - saagarjha 6y ago
      As someone who is not very good at JavaScript reverse engineering, I would tend to agree that minifiers are pretty annoying.
      - wglb 6y ago
        So the first thing that I do with one of those is to parse it and convert it to s-expressions. Problem solved.
- perl4ever 6y ago
  >simply set a breakpoint I knew nothing about this topic in general, but elsewhere in this thread there was a link to a blog post about obfuscation methods used in a piece of commercial software. One item was a function that detects a breakpoint, obfuscates its boolean return value so you can't tell if it did, and makes the program hang when it does. Pretty neat. I think your (and my) ignorance of such methods is evidence that they probably are reasonably effective, even though when explained, they're not quantum physics.
weare138 6y ago
Let me give you an example. At a previous job as a devops, of my predecessors frequently used these "techniques, minus the encrypted database but I sure he would have done it if he knew how. So there was some buggy internal app they needed some new features added to and the person who wrote it thought he was clever and obfuscated the code. It took me a whopping 30 minutes churn through his 'clever' obfuscation scheme and the randomized variable were just a nuisance. Honestly his best obfuscation technique was his horrible code that made no sense. Even OP's advice about running services on non-standard ports isn't sound. Who doesn't run a service scan? Even sites like Shodan do service discovery for you. I'm going to find whatever port your running ssh on if your running it.
- umvi 6y ago
  > I'm going to find whatever port your running ssh on if your running it. Not if you have to port knock before the ssh port is open to new connections.
  - gowld 6y ago
    Why not? I'll run my automated port knocker
    - umvi 6y ago
      Huh? How would that work? You have no idea what my port knocking scheme is. For all you know you have to knock ports 22, 46, 1776, and 8998 to the timing of "shave and a haircut" switching between udp and icmp along the way... Good luck, the entropy you have to overcome is astronomical.
    - minerjoe 6y ago
      I would thing that blocking IP's of insessant knockers would be easy to implement.
      - pravda 6y ago
        They use proxies! So many proxies.
wglb 6y ago
>Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit. It is not "some people" that I worry about. I worry about attackers with a level of skill. As I noted elsewhere in the thread, I have audited obfuscated code and the obfuscation is only a speed bump. I can only presume that attackers are smarter than I am, and obfuscation is effectively not an issue. And it is not an order of magnitude. This is another example of developer thinking that this form of obscurity is of any real value. Reviewing code will tell you if eigenvector_coefficient is really what it claims to be or something that morphed into something that the developer didn't originally intend. Also keep in mind that code reviews approach code from a totally different angle than a developer would either developing or during a code walkthrough.

by umvi 6y ago

aeternum 6y ago

It might make sense in some contexts, but code obfuscation is a great example of where software engineers think it provides security where it provides none. Developers often have some idealized notion that an attacker is going to need to piece their program logic back together and try to decode the purpose of each obfuscated variable in order to find a hardcoded password/value. In reality an attacker is just going to dump strings and try them all or simply set a breakpoint just before the important syscall and let your program do the work. Code obfuscation provides little to no value for these common methods, yet we cannot resist the urge to list it as a bullet point in security meetings, leading to a false sense of security.

saagarjha 6y ago
Exactly. If you're running crypto and think getting rid of variable names is going to stop people; it's not. Any off-the-shelf algorithm is usually easy to recognize to an accomplished reverse engineer with a basic background of what kind of things they're looking for.
- XMPPwocky 6y ago
  Honestly, the modern JavaScript toolchain is better at giving reverse engineers a headache than 80% of binary obfuscators.
  - saagarjha 6y ago
    As someone who is not very good at JavaScript reverse engineering, I would tend to agree that minifiers are pretty annoying.
    - wglb 6y ago
      So the first thing that I do with one of those is to parse it and convert it to s-expressions. Problem solved.
perl4ever 6y ago
>simply set a breakpoint I knew nothing about this topic in general, but elsewhere in this thread there was a link to a blog post about obfuscation methods used in a piece of commercial software. One item was a function that detects a breakpoint, obfuscates its boolean return value so you can't tell if it did, and makes the program hang when it does. Pretty neat. I think your (and my) ignorance of such methods is evidence that they probably are reasonably effective, even though when explained, they're not quantum physics.

weare138 6y ago

Let me give you an example. At a previous job as a devops, of my predecessors frequently used these "techniques, minus the encrypted database but I sure he would have done it if he knew how. So there was some buggy internal app they needed some new features added to and the person who wrote it thought he was clever and obfuscated the code. It took me a whopping 30 minutes churn through his 'clever' obfuscation scheme and the randomized variable were just a nuisance. Honestly his best obfuscation technique was his horrible code that made no sense. Even OP's advice about running services on non-standard ports isn't sound. Who doesn't run a service scan? Even sites like Shodan do service discovery for you. I'm going to find whatever port your running ssh on if your running it.

umvi 6y ago
> I'm going to find whatever port your running ssh on if your running it. Not if you have to port knock before the ssh port is open to new connections.
- gowld 6y ago
  Why not? I'll run my automated port knocker
  - umvi 6y ago
    Huh? How would that work? You have no idea what my port knocking scheme is. For all you know you have to knock ports 22, 46, 1776, and 8998 to the timing of "shave and a haircut" switching between udp and icmp along the way... Good luck, the entropy you have to overcome is astronomical.
  - minerjoe 6y ago
    I would thing that blocking IP's of insessant knockers would be easy to implement.
    - pravda 6y ago
      They use proxies! So many proxies.

wglb 6y ago

>Believe it or not, nuisances are enough to stop some people. A lot of would be attackers are just cruising for low hanging fruit. It is not "some people" that I worry about. I worry about attackers with a level of skill. As I noted elsewhere in the thread, I have audited obfuscated code and the obfuscation is only a speed bump. I can only presume that attackers are smarter than I am, and obfuscation is effectively not an issue. And it is not an order of magnitude. This is another example of developer thinking that this form of obscurity is of any real value. Reviewing code will tell you if eigenvector_coefficient is really what it claims to be or something that morphed into something that the developer didn't originally intend. Also keep in mind that code reviews approach code from a totally different angle than a developer would either developing or during a code walkthrough.