Re: Black Box Tesing v White Box Testing

2019-12-05 Thread Zahid Rahman
Hi, > "None of us are resistant to new ideas or ways of looking at things" Happy LEARNING https://www.robotshop.com/uk/37-modules-sensor-kit-arduino.html https://www.raspberrypi.org/ https://beagleboard.org/bone On Wed, 4 Dec 2019 at 14:11, Dave Newton wrote: > On Wed, Dec 4, 2019 at

Re: Black Box Tesing v White Box Testing

2019-12-05 Thread Zahid Rahman
On one occasion I had to make use of external procedure (dynamic link library (DLL)) on a database. The Oracle documents showed,Oracle database provides two ways of interacting with host operating system. PL/SQL which can create and write files to disk or a developer can create dll (in C or

Re: Black Box Tesing v White Box Testing

2019-12-04 Thread Dave Newton
On Wed, Dec 4, 2019 at 07:56 Zahid Rahman wrote: > The space and defence don't share what they are doing. So I don't think > yours is reasonable statement that you know what is happening in the > aerospace and defence industry. Hm. I don't think your assumption that I haven't done defense

Re: Black Box Tesing v White Box Testing

2019-12-04 Thread Zahid Rahman
The space and defence don't share what they are doing. So I don't think yours is reasonable statement that you know what is happening in the aerospace and defence industry. Anyway you jumped to a conclusion of reverse engineering when I was referring to the benefit of traceability when using

Re: Black Box Tesing v White Box Testing

2019-12-04 Thread Dave Newton
On Wed, Dec 4, 2019 at 07:37 Zahid Rahman wrote: > I'm not talking of reverse engineering, my point is traceability. Sure you are--you specifically brought up decompiling, which is the first step of reverse-engineering. And in a jar with no debug info, or obfuscation, it's not the last step.

Re: Black Box Tesing v White Box Testing

2019-12-04 Thread Dave Newton
On Wed, Dec 4, 2019 at 06:36 Zahid Rahman wrote: > You're right except in a bespoke hardware , software environment they tend > to use 68k Motorola chip to eliminate internal unknown risks. I haven't worked on a 68k product for twenty years--I'd be *very* surprised if anyone had designed one

Re: Black Box Tesing v White Box Testing

2019-12-04 Thread Zahid Rahman
I'm not talking of reverse engineering, my point is traceability. If you can decompile code then if there is a problem then there is a chance that you can trace it. With .exe or dll you cannot trace the problem. On Wed, 4 Dec 2019, 11:06 Dave Newton, wrote: > On Wed, Dec 4, 2019 at 01:16

Re: Black Box Tesing v White Box Testing

2019-12-04 Thread Zahid Rahman
You're right except in a bespoke hardware , software environment they tend to use 68k Motorola chip to eliminate internal unknown risks. On Wed, 4 Dec 2019, 11:06 Dave Newton, wrote: > On Wed, Dec 4, 2019 at 01:16 Zahid Rahman wrote: > > > .exe and DLLs (C,C++) have unknown internals

Re: Black Box Tesing v White Box Testing

2019-12-04 Thread Zahid Rahman
Thanks for a most respectful reply. I will give details of an incident later. On Wed, 4 Dec 2019, 11:06 Dave Newton, wrote: > On Wed, Dec 4, 2019 at 01:16 Zahid Rahman wrote: > > > .exe and DLLs (C,C++) have unknown internals (AFAIK DLLs can't be > > decompiled). > > > They're just code

Re: Black Box Tesing v White Box Testing

2019-12-04 Thread Dave Newton
On Wed, Dec 4, 2019 at 01:16 Zahid Rahman wrote: > .exe and DLLs (C,C++) have unknown internals (AFAIK DLLs can't be > decompiled). They're just code like anything else. And I don’t quite understand why there’s a distinction made here between reverse engineering an exe and a jar. I also