Liberty BASIC Community Forum
« Search Results »

Welcome Guest. Please Login or Register.
Mar 4th, 2015, 05:11am

Rules|Home|Help|Search|Recent Posts|Notification

--Liberty BASIC Resources--
Yahoo Code Repository (source must be included)
Liberty BASIC Community WikiSpace
Liberty Labs
Bay Six Software Forum
Liberty BASIC Home Page

Official Liberty BASIC Support
Liberty BASIC Programmer's Encyclopedia
Liberty BASIC 5 Handbook
Liberty BASIC on Rosetta Code

Search Results

Total results: 10

 1   Novice / Re: PEEK  on: Today at 04:29am
Started by CS | Post by Colin McMurchie
Hi Steve,

You are not paranoid, but I do recognise the itch that all coders have from time to time, whether professional or just dabblers like myself. There must be a way to do it!
For me it is about translating sound files from 'equal temprement' to 'just intonation'. I am still searching.

I hope you are successful, and if so, that you post a little of how you did it here.

In the meantime, I am reminded of a little poem that my mother used to say. I think of it as the definition of an optimist.

They told him it could not be done.
With a smile he went right to it,
and tackled that thing that could not be done,
and could not do it!

good luck, Colin
  Reply Quote Notify of replies

 2   Novice / Re: PEEK  on: Today at 03:53am
Started by CS | Post by CS

I did not realize there were so many obstacles to this, it is something I have done in the in the past. I have had software on Windows PC's that have done this, not written by me, so I know it can be done albeit with a different language.

I am not looking to use public encryption keys for my encryption, I am writing my own systems for encryption.

The reason I want the software "self contained" is to make it much harder too spoof anything, I also know that no system is perfect and any encryption can be broken.

You could always just consider me as paranoid.


  Reply Quote Notify of replies

 3   Novice / Re: PEEK  on: Yesterday at 3:52pm
Started by CS | Post by Chris Iverson
Do you specifically, actually need it restricted by machine, or will secure encryption work?

Because you could still use public-key encryption certificates to do the encryption. Store the secret keys only on those two computers, and they'll only be able to encrypt for each other. (The secret key can be moved to another computer, though. Might be useful if hardware goes bad.)

If you need it by machine, you could use some hardware ID on the machine as part of the passphrase to secure the secret key. That way, if your program is accessing the secret key, it will only be able to do so successfully on the right machine.

Heck, you could store the secret keys on the USB dongles. That way, only a machine with the dongle could be able to decrypt the data.

This by no means prevents spoofing or data tampering on the endpoints, though. If your program is running, it will likely have either the passphrase or the secret key itself in its own memory, and users could access that directly with help from the system.

You could run it is a privileged application to prevent that, but then you have to secure the app itself against other attacks that are only trying to leverage the application's admin rights. And even then, other privileged apps will still be able to pluck that data out.

Why are you so convinced that you have to push your code to kernel-level access right away, no matter the OS?

You're still going to have to have different methods of doing so, since kernel stuff is different for each OS.

You're going to need a user-mode component to run the user interface, and that component can still be hacked and spoofed.

I appreciate the need for security, but what exactly is being transferred that the risk of destabilizing production machines is worth it?
  Reply Quote Notify of replies

 4   General Board / trying to run LibertyBasic4.5  on: Yesterday at 3:33pm
Started by fishfinatic | Post by fishfinatic
I am running 4.4. Saw this post and followed upload but get erro message run45.tkn not found

Thank You


  Reply Quote Notify of replies

 5   Novice / Re: PEEK  on: Yesterday at 3:32pm
Started by CS | Post by CS

The machines will will not be locked down in any way by me, they will be machines that the customer can specify.

I want to make the software totally self contained and not reliant on any external 'help' from an operating system. Hence the need to be able to verify the machines identity via direct access to the hardware.

The basic idea being, user 1 on machine one creates a message, the program encrypts it. User 1 can then send the output file either via email or upload it to a server. User 2 then retrieves the file and decrypts it. Each user will have a machine, USB dongle and software provided as a matched pair. Only the right machine, with the right USB dongle and the correct password will be able to view the data transmitted.


  Reply Quote Notify of replies

 6   Novice / Re: PEEK  on: Yesterday at 10:46am
Started by CS | Post by Chris Iverson
If you're selling the complete machines, will you be locking down the install and usage of them? Or will they still be able to be used as general purpose machines?

If you're completely locking them down, so that even the user doesn't have access to modify the system, I would just create SSL certificates for both machines, have them trust each other's certs, and use an SSL/TLS channel for communications. Any data sent between the two machines will be both encrypted and verified by both ends.

As long as you verify the fingerprints of the certificates before letting each end fully establish the connection, you should be able to lower the risk of MITM attacks.
  Reply Quote Notify of replies

 7   Novice / Re: PEEK  on: Yesterday at 06:08am
Started by CS | Post by CS

I have already worked on/with USB dongles and find they work well, had not thought of using them internally though.

I would be selling pair of machines with software written for each machine to communicate with the other machine only.


  Reply Quote Notify of replies

 8   Novice / Re: PEEK  on: Mar 2nd, 2015, 4:45pm
Started by CS | Post by tenochtitlanuk
There might be some mileage in USB security dongles- you could fit these to the internal spare USB connector to individualize the machines but not be externally visible. Your software could write/read to just an internal memory stick/card reader if you didn't go for a commercial dongle. Someone investigating your machine would have no idea what any files there were for, especially if encrypted...
Just a thought. I agree with all that's been said about direct access to memory that bypasses normal Windows/Unix OS.
  Reply Quote Notify of replies

 9   Game and Graphic Programming / Re: ray tracer 3  on: Mar 2nd, 2015, 06:45am
Started by bluatigro | Post by bluatigro
update :
- more functions

error :
- black screen

''bluatigro 1 mrt 2015
''rebild of internet raytracer
'constants to access the point arrays
global X,Y,Z,R,clr,Xp,Yp,DistToScreen,maxObjects
X = 0
Y = 1
Z = 2
R = 3
clr = 4

global sptel
'the world is 24x24 units
'0,0 is centre of the world
'-12 far left 12 far right
'12 top -12 bottom
'objects are specified in world units
'rays are specified in world units
'pixel coordinates are converted by
'dividing the world width by the screen width
'and the world height by the screen height
'this gives a per pixel world increment value

global ScrXleft , ScrXRight , ScrYTop , ScrYBottom
global ImgX , ImgY , ScrX , Scry
ImgX=512 'pixel width of screen
ImgY=512 'pixel height of screen
ScrX=2*ScrXRight/ImgX 'per pixel world increment value

'Calculate how much space windows borders take
'Anatoly's tip
WindowWidth = 200
WindowHeight = 200
open "Ajusting..." for graphics_nsb as #1
  #1, "home ; down ; posxy w h"
  w=200-2*w : h = 200-2*h
  'w and h now contain the number of pixels
  'the Windows scheme/theme takes
close #1
WindowWidth  = ImgX+w
WindowHeight = ImgY+h
UpperLeftX = int((DisplayWidth-WindowWidth)/2)
UpperLeftY = int((DisplayHeight-WindowHeight)/2)
open "Raytrace" for graphics_nsb as #1
  #1  "down ; fill black ; trapclose [quit]"

  global red , green , blue , gray 

  red = rgb( 255 , 0 , 0 )
  green = rgb( 0 , 255 , 0 )
  blue = rgb( 0 , 0 , 255 )
  gray = rgb( 200 , 200 , 200 )

  'sphere data x,y,z,radius,color
  'three spheres ,red green and blue
  'evenly spaced around centre of screen
  'z order front to back blue, green, red

  'there are five massive spheres positioned
  'all round the edges and to the rear to create walls

  maxObjects = 10
  dim sp( maxObjects , 4 )
  call sphere 0,0,5 , 4 , red
  call sphere 0,5,2 , 2 , green
  call sphere 6,0,2 , 2 , blue
  call sphere -1e5-12,20,26 , 1e5 , gray
  call sphere 1e5+12,20,26 , 1e5 , gray
  call sphere 0,-1e5-12,26 , 1e5 , gray
  call sphere 0,1e5+12,26 , 1e5 , gray
  call sphere 0,0,1e5+12 , 1e5 , gray

  'point origin of camera
  'centre screen, 24 world units back from the image plane
  cam(X) = 0
  cam(Y) = 0
  cam(Z) = -24

  'point origin of light source
  'centre top, on the image plane
  lit(X) = -11
  lit(Y) = -11
  lit(Z) = -11

  call render
  notice "ready !!"

sub render
'now cast a ray through every pixel on the screen

  for Xp=0 to ImgX
    for Yp=0 to ImgY

      'point0, the camera x,y,z
      o(X) = cam(X)                     'world x camera 0
      o(Y) = cam(Y)                     'world y camera 0
      o(Z) = cam(Z)                     'world z camera -10

      'point1, the screen x,y,z  
      'which is ScrXLeft (-12) + .5 * ScrX, the per pixel world increment value
      'to which we add xp * ScrX to give world x in world units
      r(X) = ScrXLeft + 0.5 * ScrX + Xp * ScrX   'world x
      r(Y) = ScrYTop + 0.5 * ScrY + Yp * ScrY    'world y
      r(Z) = 0                          'world z image plane 0

      'flat parrallell ray no perspective  

      'subtract point0 from point1 to get vector direction d()
      d(X) = r(X) - o(X)
      d(Y) = r(Y) - o(Y)
      d(Z) = r(Z) - o(Z)

      'normalize it by dividing by its length to make a unit vector ie it sums to 1
      l = sqr( d(X) * d(X) + d(Y) * d(Y) + d(Z) * d(Z) )
      d(X) = d(X) / l
      d(Y) = d(Y) / l
      d(Z) = d(Z) / l
      DistToScreen = l

      'go look for an intersect
      null = raySphereIntersect()
    next 'y
  next 'x
end sub
  close #1
function nr$( no , digits )
  nr$ = right$( "0000000000" ; no , digits )
end function
sub savescreen a$
  #1  "getbmp screen 0 0 " ; ImgX ; " " ; ImgY
  bmpsave "screen" , a$ + ".bmp"
end sub
function rgb( a , b , c )
  rgb = a + b * 256 + c * 256 ^ 2
end function
function clr.r( kl )
  clr.r = kl and 255
end function
function clr.g( kl )
  clr.g = int( kl / 256 ) and 255
end function
function clr.b( kl )
  clr.b = int( kl / 256 ^ 2 ) and 255
end function
sub sphere a , b , c , d , kl
  if sptel >= maxObjects then exit sub
  sp( sptel , X ) = a
  sp( sptel , Y ) = b
  sp( sptel , Z ) = c
  sp( sptel , R ) = d
  sp( sptel , clr ) = kl
  sptel = sptel + 1
end sub
function Sphere.dist( o )
  uit = 1e7
  b = 2 * d(X) * ( o(X) - sp(o,X)) _
    + 2 * d(Y) * ( o(Y) - sp(o,Y)) _
    + 2 * d(Z) * ( o(Z) - sp(o,Z))
  c = ( o(X) - sp(o,X) ) ^ 2 _
    + ( o(Y) - sp(o,Y) ) ^ 2 _
    + ( o(Z) - sp(o,Z) ) ^ 2 - sp(o,R) ^ 2
  d = b * b - 4 * c
  if d > 0 then
    uit = ( b * -1 - sqr( b * b - 4 * c ) ) / 2
  end if
  Sphere.dist = uit
end function
function raySphereIntersect()
  maxdist = 1e7
  for o = 0 to sptel
    t = Sphere.dist( o )
    if t > DistToScreen  then
    'store the shortest intersect of all sphere intersects
      if t < maxdist then maxdist = t : id = o
    end if
  if maxdist < 1e7 then
  'establish the sphere surface intersect point
    i(X) = o(X) + d(X) * maxdist
    i(Y) = o(Y) + d(Y) * maxdist
    i(Z) = o(Z) + d(Z) * maxdist
  'get unit normal vector from sphere centre to surface intersect
    n(X) = ( i(X) - sp(id,X) ) / sp(id,R)
    n(Y) = ( i(Y) - sp(id,Y) ) / sp(id,R)
    n(Z) = ( i(Z) - sp(id,Z) ) / sp(id,R)
  'get the unit normal vector from sphere surface intersect to the light
    l(X) = lit(X) - i(X)
    l(Y) = lit(Y) - i(Y)
    l(Z) = lit(Z) - i(Z)
    l = sqr( l(X) * l(X) + l(Y) * l(Y) + l(Z) * l(Z) )
    l(X) = l(X) / l
    l(Y) = l(Y) / l
    l(Z) = l(Z) / l
  'the dot product of these vectors gives an indication of the light
    color = n(X) * l(X) + n(Y) * l(Y) + n(Z) * l(Z)

  'cast a ray from intersect to the light to check for shadow
  'we have done most of the ray prep
  'point0 is the intersect point1 is the light
  'so l() is our ray direction, point1-point0, normalized
    shadow = 1
    o(X) = i(X)
    o(Y) = i(Y)
    o(Z) = i(Z)
    d(X) = l(X)
    d(Y) = l(Y)
    d(Z) = l(Z)
    for o = 0 to sptel
      if o <> id then  
      'check a ll other spheres not the one we are currently considering
        t = Sphere.dist( o )
        if t > 0 and t < 1e7 then shadow = 0.5 : exit function
      end if

    'add some ambient light
    if color < .3 then color = .3

    kl = sp( id , clr )
    'color the pixel
    #1 "color " ; clr.r( kl ) * color * shadow _
          ; " " ; clr.g( kl ) * color * shadow _
          ; " " ; clr.b( kl ) * color * shadow
    #1 "set " ; Xp ; " " ; Yp
    #1 "color black"
    #1 "set " ; Xp ; " " ; Yp
  end if
end function


  Reply Quote Notify of replies

 10   Novice / Re: PEEK  on: Mar 1st, 2015, 7:09pm
Started by CS | Post by Chris Iverson
No matter what system it runs on, LB5 will be purely a user-mode application, and therefore, any access it has to the hardware will be only through the OS itself.

To have any chance at any more security, and to even be able to interface with the hardware directly, you would need to write your own kernel-mode code. This means device drivers for Windows, and kernel plugins at the very least in Linux, if not device drivers there as well.

This also means meeting the requirements for kernel-mode code, which are steep on Windows, for good reason. Kernel-mode code has the ability to do anything in the system, and so, nowadays, anyone who wants to put kernel-mode code into production and distribution needs to have the final code signed. Code-signing certificates valid for Windows device drivers are expensive, and your driver will not run on any modern Windows system without them. (In general, at least. For testing, you can turn off device driver signature checks temporarily on your own system, or you can install Microsoft's test driver certificate. Doing that will notify every user of the system that the system is running unverified drivers.)

This kind of thing is far beyond the scope of LB, and because of the security and reliability issues, it is far beyond the realm of a novice.

Again, your kernel-mode code can access ANYTHING. Crackers WILL be looking over it for ways to exploit it and get kernel-mode access themselves. And bugs in a user-mode program crash the program. Bugs in kernel-mode programs crash the operating system. Your customers won't be happy to see blue screens of death or kernel panics caused by you.
  Reply Quote Notify of replies

Rules|Home|Help|Search|Recent Posts|Notification

Donate $6.99 for 50,000 Ad-Free Pageviews!

| |

This forum powered for FREE by Conforums ©
Sign up for your own Free Message Board today!
Terms of Service | Privacy Policy | Conforums Support | Parental Controls