Re: Black Box Tesing v White Box Testing

[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 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 contracting
> is a reasonable one, but we'll agree to disagree on that one. (If you're
> wondering, encrypted radio systems, and consulting on guidance systems. And
> I still know the people I worked with--and people that use the systems or
> their descendents.)
>
> FWIW: you're going to find people with a pretty wide background in this
> group, many with decades of experience across a full spectrum of domains.
> Speaking for myself, I come from both embedded and application development
> going on 30+ years now. I know others here have similar time in the
> trenches. None of us are resistant to new ideas or ways of looking at
> things--but we have an appreciation for factual claims and accurate
> representations.
>
> Anyway you jumped to a conclusion of reverse engineering  when I was
> > referring to the benefit of traceability when using interpretive code.
>
>
> I "jumped" to reverse engineering because you specifically said an
> advantage of Java was decompilation (not unique to Java), and that's a
> primary component of reverse engineering almost by definition.
>
> d.
> --
> em: davelnew...@gmail.com
> mo: 908-380-8699
> tw: @dave_newton 
> li: dave-newton 
> gh: davelnewton 
> so: Dave Newton 
> bl[0]: Bucky Bits 
> bl[1]: Maker's End Blog 
> sk: davelnewton_skype
>

Re: Black Box Tesing v White Box Testing

[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 other 3rd generation language).

There were code example in the documents  showing how to use PL/SQL for one
way interaction with OS , but no example showing C dll interface code .Any
way I decided to give it go nonetheless.

The first problem was every time I tried to install the C/C++ IDE. It would
crash with an incomprehensible error message  i.e. ("OX56F...).

Then I asked myself how did the IDE vendor compile the ide on that
operating.

I asked my internal support staff for any patches for available. It was a
fully licenced environment, so he had a CD delivered with the patches. I
loaded the patches and the IDE installed with out any issues.

Then the DLL wouldn't produce the expected results.

I contacted Oracle  support because we had a support contract.  The
Database Vendor support said we don't support it on that operating system.
Hmmm...

So it would appear the reason there was no sample code in the documents is
because the database vendor couldn't  install the IDE.














On Wed, 4 Dec 2019, 14:11 Dave Newton,  wrote:

> 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 contracting
> is a reasonable one, but we'll agree to disagree on that one. (If you're
> wondering, encrypted radio systems, and consulting on guidance systems. And
> I still know the people I worked with--and people that use the systems or
> their descendents.)
>
> FWIW: you're going to find people with a pretty wide background in this
> group, many with decades of experience across a full spectrum of domains.
> Speaking for myself, I come from both embedded and application development
> going on 30+ years now. I know others here have similar time in the
> trenches. None of us are resistant to new ideas or ways of looking at
> things--but we have an appreciation for factual claims and accurate
> representations.
>
> Anyway you jumped to a conclusion of reverse engineering  when I was
> > referring to the benefit of traceability when using interpretive code.
>
>
> I "jumped" to reverse engineering because you specifically said an
> advantage of Java was decompilation (not unique to Java), and that's a
> primary component of reverse engineering almost by definition.
>
> d.
> --
> em: davelnew...@gmail.com
> mo: 908-380-8699
> tw: @dave_newton 
> li: dave-newton 
> gh: davelnewton 
> so: Dave Newton 
> bl[0]: Bucky Bits 
> bl[1]: Maker's End Blog 
> sk: davelnewton_skype
>

Re: Black Box Tesing v White Box Testing

[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 contracting
is a reasonable one, but we'll agree to disagree on that one. (If you're
wondering, encrypted radio systems, and consulting on guidance systems. And
I still know the people I worked with--and people that use the systems or
their descendents.)

FWIW: you're going to find people with a pretty wide background in this
group, many with decades of experience across a full spectrum of domains.
Speaking for myself, I come from both embedded and application development
going on 30+ years now. I know others here have similar time in the
trenches. None of us are resistant to new ideas or ways of looking at
things--but we have an appreciation for factual claims and accurate
representations.

Anyway you jumped to a conclusion of reverse engineering  when I was
> referring to the benefit of traceability when using interpretive code.


I "jumped" to reverse engineering because you specifically said an
advantage of Java was decompilation (not unique to Java), and that's a
primary component of reverse engineering almost by definition.

d.
-- 
em: davelnew...@gmail.com
mo: 908-380-8699
tw: @dave_newton 
li: dave-newton 
gh: davelnewton 
so: Dave Newton 
bl[0]: Bucky Bits 
bl[1]: Maker's End Blog 
sk: davelnewton_skype

Re: Black Box Tesing v White Box Testing

[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 interpretive code.








On Wed, 4 Dec 2019, 12:40 Dave Newton,  wrote:

> 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 into a system in the last decade or more. I'm
> not sure if they still produce the hardened version, but I don't recall
> many space-based systems using them, although it was in some military
> hardware--a long time ago.
>
> But that's not really relevant--almost nobody does embedded systems work;
> it's an edge-case.
>
>
> --
> em: davelnew...@gmail.com
> mo: 908-380-8699
> tw: @dave_newton 
> li: dave-newton 
> gh: davelnewton 
> so: Dave Newton 
> bl[0]: Bucky Bits 
> bl[1]: Maker's End Blog 
> sk: davelnewton_skype
>

Re: Black Box Tesing v White Box Testing

[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.

(And not getting into external modifications to a jar which could happen
during load.)

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.


Of course you can--it's just software. It's how we used too develop all the
time.

-- 
em: davelnew...@gmail.com
mo: 908-380-8699
tw: @dave_newton 
li: dave-newton 
gh: davelnewton 
so: Dave Newton 
bl[0]: Bucky Bits 
bl[1]: Maker's End Blog 
sk: davelnewton_skype

Re: Black Box Tesing v White Box Testing

[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 into a system in the last decade or more. I'm
not sure if they still produce the hardened version, but I don't recall
many space-based systems using them, although it was in some military
hardware--a long time ago.

But that's not really relevant--almost nobody does embedded systems work;
it's an edge-case.


-- 
em: davelnew...@gmail.com
mo: 908-380-8699
tw: @dave_newton 
li: dave-newton 
gh: davelnewton 
so: Dave Newton 
bl[0]: Bucky Bits 
bl[1]: Maker's End Blog 
sk: davelnewton_skype

Re: Black Box Tesing v White Box Testing

[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 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 chose Java because one can decompile  classes , so any unknown
> > behaviour can be identified ,
>
>
> Decompiling a jar is a small part of understanding its behavior in a
> system. A variety of mechanisms can alter library behavior during load and
> run time, plus the additional layer of abstraction from the JVM, plus some
> indeterminism depending on what GC and JRE decisions were made.
>
> In any case, unless you’re running on bare metal and assuming we’re
> ignoring cpu unknowns, we’re working in black box environments most of the
> time anyway—it’s just that most of the time we have the luxury of being
> able to ignore this.
>
> --
> em: davelnew...@gmail.com
> mo: 908-380-8699
> tw: @dave_newton 
> li: dave-newton 
> gh: davelnewton 
> so: Dave Newton 
> bl[0]: Bucky Bits 
> bl[1]: Maker's End Blog 
> sk: davelnewton_skype
>

Re: Black Box Tesing v White Box Testing

[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 (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 chose Java because one can decompile  classes , so any unknown
> > behaviour can be identified ,
>
>
> Decompiling a jar is a small part of understanding its behavior in a
> system. A variety of mechanisms can alter library behavior during load and
> run time, plus the additional layer of abstraction from the JVM, plus some
> indeterminism depending on what GC and JRE decisions were made.
>
> In any case, unless you’re running on bare metal and assuming we’re
> ignoring cpu unknowns, we’re working in black box environments most of the
> time anyway—it’s just that most of the time we have the luxury of being
> able to ignore this.
>
> --
> em: davelnew...@gmail.com
> mo: 908-380-8699
> tw: @dave_newton 
> li: dave-newton 
> gh: davelnewton 
> so: Dave Newton 
> bl[0]: Bucky Bits 
> bl[1]: Maker's End Blog 
> sk: davelnewton_skype
>

Re: Black Box Tesing v White Box Testing

[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 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 chose Java because one can decompile  classes , so any unknown
> > behaviour can be identified ,
>
>
> Decompiling a jar is a small part of understanding its behavior in a
> system. A variety of mechanisms can alter library behavior during load and
> run time, plus the additional layer of abstraction from the JVM, plus some
> indeterminism depending on what GC and JRE decisions were made.
>
> In any case, unless you’re running on bare metal and assuming we’re
> ignoring cpu unknowns, we’re working in black box environments most of the
> time anyway—it’s just that most of the time we have the luxury of being
> able to ignore this.
>
> --
> em: davelnew...@gmail.com
> mo: 908-380-8699
> tw: @dave_newton 
> li: dave-newton 
> gh: davelnewton 
> so: Dave Newton 
> bl[0]: Bucky Bits 
> bl[1]: Maker's End Blog 
> sk: davelnewton_skype
>

Re: Black Box Tesing v White Box Testing

[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 chose Java because one can decompile  classes , so any unknown
> behaviour can be identified ,


Decompiling a jar is a small part of understanding its behavior in a
system. A variety of mechanisms can alter library behavior during load and
run time, plus the additional layer of abstraction from the JVM, plus some
indeterminism depending on what GC and JRE decisions were made.

In any case, unless you’re running on bare metal and assuming we’re
ignoring cpu unknowns, we’re working in black box environments most of the
time anyway—it’s just that most of the time we have the luxury of being
able to ignore this.

-- 
em: davelnew...@gmail.com
mo: 908-380-8699
tw: @dave_newton 
li: dave-newton 
gh: davelnewton 
so: Dave Newton 
bl[0]: Bucky Bits 
bl[1]: Maker's End Blog 
sk: davelnewton_skype