Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.raspberry-pi > #25425 > unrolled thread
| Started by | gareth evans <headstone255@yahoo.com> |
|---|---|
| First post | 2021-01-04 11:00 +0000 |
| Last post | 2021-02-12 15:40 +0000 |
| Articles | 20 on this page of 157 — 28 participants |
Back to article view | Back to comp.sys.raspberry-pi
AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-04 11:00 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-04 11:42 +0000
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-04 13:08 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-04 17:51 +0000
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-04 21:57 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-04 22:23 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 23:09 +0000
Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-04 17:50 -0500
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-04 23:00 +0000
Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-04 16:59 -0700
Re: AI and decompilation? J. Clarke <jclarke.873638@gmail.com> - 2021-01-04 20:42 -0500
Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-04 20:59 -0500
Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-04 20:55 -0500
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-05 10:38 +0000
Re: AI and decompilation? Bob Eager <news0073@eager.cx> - 2021-01-05 12:46 +0000
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-05 13:43 +0000
Re: AI and decompilation? Bob Eager <news0073@eager.cx> - 2021-01-05 14:23 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:22 +0000
Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-05 09:05 -0500
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 10:51 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-05 11:52 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 12:06 +0000
Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-05 20:12 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 11:45 +0000
Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-05 14:25 -0700
Re: AI and decompilation? J. Clarke <jclarke.873638@gmail.com> - 2021-01-04 20:38 -0500
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 11:54 +0000
Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-05 14:06 -0700
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 22:52 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 10:29 +0000
Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-04 11:05 -0500
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-04 17:07 +0000
Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-04 17:52 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 10:28 +0000
Re: AI and decompilation? Thomas Koenig <tkoenig@netcologne.de> - 2021-01-05 13:06 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 13:41 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:30 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-05 16:42 +0000
Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-05 20:12 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 20:20 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-05 22:23 +0000
Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-06 00:14 +0000
Re: AI and decompilation? Eli the Bearded <*@eli.users.panix.com> - 2021-01-06 02:17 +0000
Re: AI and decompilation? Björn Lundin <b.f.lundin@gmail.com> - 2021-01-08 14:39 +0100
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-08 15:07 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-08 15:56 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-08 15:35 +0000
Re: AI and decompilation? Eli the Bearded <*@eli.users.panix.com> - 2021-01-08 20:02 +0000
Re: AI and decompilation? Björn Lundin <b.f.lundin@gmail.com> - 2021-01-10 15:12 +0100
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 09:36 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 10:43 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 18:09 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 18:29 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 18:37 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 21:03 +0000
Re: AI and decompilation? Björn Lundin <b.f.lundin@gmail.com> - 2021-01-08 14:45 +0100
Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-08 18:06 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-08 18:44 +0000
Re: AI and decompilation? A. Dumas <alexandre@dumas.fr.invalid> - 2021-01-09 03:02 +0000
Re: AI and decompilation? A. Dumas <alexandre@dumas.fr.invalid> - 2021-01-09 02:58 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-06 18:35 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 18:39 +0000
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-06 19:03 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 19:08 +0000
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-06 19:19 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-07 04:07 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-07 12:59 +0000
Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-08 21:41 -0500
Re: AI and decompilation? Pancho <Pancho.Dontmaileme@outlook.com> - 2021-01-09 12:25 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-09 12:46 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 15:49 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-09 18:33 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 19:20 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-09 21:05 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 23:19 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 12:17 +0000
Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-09 16:54 -0500
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 23:48 +0000
Re: AI and decompilation? A. Dumas <alexandre@dumas.fr.invalid> - 2021-01-10 02:00 +0000
Re: AI and decompilation? druck <news@druck.org.uk> - 2021-01-09 18:36 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 19:28 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 12:15 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-10 12:33 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-10 13:18 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 14:01 +0000
Re: AI and decompilation? TimS <timstreater@greenbee.net> - 2021-01-10 15:14 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 13:59 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-10 14:46 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-10 15:34 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-10 15:05 +0000
Re: AI and decompilation? Axel Berger <Spam@Berger-Odenthal.De> - 2021-01-10 17:28 +0100
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-11 17:25 +0000
Re: AI and decompilation? TimS <timstreater@greenbee.net> - 2021-01-10 15:13 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-10 15:35 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-10 15:35 +0000
Re: AI and decompilation? TimS <timstreater@greenbee.net> - 2021-01-10 17:23 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-10 18:17 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-11 03:44 +0000
Re: AI and decompilation? TimS <timstreater@greenbee.net> - 2021-01-11 11:00 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-11 03:36 +0000
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-01-06 21:34 +0000
Re: AI and decompilation? druck <news@druck.org.uk> - 2021-01-06 18:37 +0000
Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-08 21:09 -0500
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-06 09:32 +0000
Re: AI and decompilation? Björn Lundin <b.f.lundin@gmail.com> - 2021-01-08 14:56 +0100
Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-05 14:25 -0700
Re: AI and decompilation? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-01-06 14:17 +0200
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-06 12:42 +0000
Re: AI and decompilation? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2021-01-06 16:42 +0200
Re: AI and decompilation? "Kerr-Mudd,John" <notsaying@127.0.0.1> - 2021-01-08 09:48 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-08 10:27 +0000
Re: AI and decompilation? usenet@only.tnx (Questor) - 2021-01-08 21:40 +0000
Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-05 14:06 -0700
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-05 22:27 +0000
Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-06 00:14 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 08:25 +0000
Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-08 21:52 -0500
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-09 15:37 +0000
Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-10 06:40 -0700
Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-06 15:15 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 16:09 +0000
Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-06 17:07 +0000
Re: AI and decompilation? Martin Gregorie <martin@mydomain.invalid> - 2021-01-06 17:38 +0000
Re: AI and decompilation? druck <news@druck.org.uk> - 2021-01-05 21:20 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-04 17:47 +0000
Re: AI and decompilation? Dan Espen <dan1espen@gmail.com> - 2021-01-04 14:18 -0500
Re: AI and decompilation? Peter Flass <peter_flass@yahoo.com> - 2021-01-04 16:54 -0700
Re: AI and decompilation? Theo <theom+news@chiark.greenend.org.uk> - 2021-01-04 23:01 +0000
Re: AI and decompilation? Eli the Bearded <*@eli.users.panix.com> - 2021-01-04 20:11 +0000
Re: AI and decompilation? Richard Kettlewell <invalid@invalid.invalid> - 2021-01-05 09:07 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-05 09:47 +0000
Re: AI and decompilation? Richard Kettlewell <invalid@invalid.invalid> - 2021-01-05 11:13 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 12:12 +0000
Re: AI and decompilation? Richard Kettlewell <invalid@invalid.invalid> - 2021-01-05 13:39 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:32 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:40 +0000
Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-05 16:02 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-05 18:27 +0000
Re: AI and decompilation? Vir Campestris <vir.campestris@invalid.invalid> - 2021-01-05 21:15 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 22:54 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 11:56 +0000
Re: AI and decompilation? A. Dumas <alexandre@dumas.fr.invalid> - 2021-01-05 14:11 +0000
Re: AI and decompilation? Bob Eager <news0073@eager.cx> - 2021-01-05 14:22 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 15:35 +0000
Re: AI and decompilation? Ahem A Rivet's Shot <steveo@eircom.net> - 2021-01-05 18:47 +0000
Re: AI and decompilation? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2021-01-05 20:15 +0000
Re: AI and decompilation? J. Clarke <jclarke.873638@gmail.com> - 2021-01-05 07:32 -0500
Re: AI and decompilation? scott@slp53.sl.home (Scott Lurndal) - 2021-01-05 16:00 +0000
Re: AI and decompilation? Adrian Caspersz <email@here.invalid> - 2021-01-05 11:26 +0000
Re: AI and decompilation? Thomas Koenig <tkoenig@netcologne.de> - 2021-01-05 13:07 +0000
Re: AI and decompilation? The Natural Philosopher <tnp@invalid.invalid> - 2021-01-05 13:42 +0000
Re: AI and decompilation? Eli the Bearded <*@eli.users.panix.com> - 2021-01-05 18:31 +0000
Re: AI and decompilation? "K. Krause" <klemens.krause@gmx.net> - 2021-01-05 16:01 +0100
Re: AI and decompilation? druck <news@druck.org.uk> - 2021-01-05 20:51 +0000
Re: AI and decompilation? gareth evans <headstone255@yahoo.com> - 2021-01-05 22:51 +0000
Re: AI and decompilation? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2021-01-08 22:23 -0500
Re: AI and decompilation? Andy Burns <usenet@andyburns.uk> - 2021-02-12 15:40 +0000
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-05 11:52 +0000 |
| Message-ID | <rt1jta$cqo$1@dont-email.me> |
| In reply to | #25463 |
On Tue, 05 Jan 2021 10:51:35 +0000, The Natural Philosopher wrote: > We aren't there, ultimately, to reproduce *the* exact source, but to > arrive at *an* editable source, that we can use. > Like science, and religion, it doesn't have to be true, to be useful, > and like science, and religion, its ultimate content will be forever > truth-indecidable. +1 -- -- Martin | martin at Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 12:06 +0000 |
| Message-ID | <rt1ko8$l44$1@dont-email.me> |
| In reply to | #25463 |
On 05/01/2021 10:51, The Natural Philosopher wrote: > > The whole process is actually covered in philosophy: It is the problem > of induction. How do you work back from results to causes? > > Given that the answer to Life The Universe and Everything was '42', what > in fact was the question? (40+2)? (6x7)? > > There are an infinite number of expressions that give that answer, and > an infinite number that don't. > > This is where Karl Poppers philosophy of science steps in. Instead of > regarding there to be One True Reason why science works, namely that > scientists are in the business of discovering the Truth, he pointed out > that just because stuff worked (and 6x7 does indeed give 42) that was no > reason to suppose that some other completely different construct might > not work equally as well, and that had indeed happened with relativity > and Newtonian gravity. > > The Problem of Induction is that many theories can give the same > predicted result. Sherlock Holmes is a sham. The Dog That Didnt Bark in > the Night didn't bark, allegedly, because it knew the thief. Why? It > might have been abducted by aliens, drugged, actually out hunting > rabbits, in a soundproof box, or the Russians did it using a robot. or > just too plumb wore out with old age to care. > > The truth is not provable. All we have is stuff that works. Given > running machine code, there are an infinite number of source codes that > might have produced it, and an infinite number that did not. > > We aren't there, ultimately, to reproduce *the* exact source, but to > arrive at *an* editable source, that we can use. > Like science, and religion, it doesn't have to be true, to be useful, > and like science, and religion, its ultimate content will be forever > truth-indecidable. > That's an interesting and thought-provoking aside!
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-01-05 20:12 +0000 |
| Message-ID | <rt2h7n2sc8@news2.newsguy.com> |
| In reply to | #25463 |
On 2021-01-05, The Natural Philosopher <tnp@invalid.invalid> wrote: > Given that the answer to Life The Universe and Everything was '42', > what in fact was the question? (40+2)? (6x7)? 9x6 - if you're working in base 13. -- /~\ Charlie Gibbs | "Some of you may die, \ / <cgibbs@kltpzyxm.invalid> | but it's a sacrifice X I'm really at ac.dekanfrus | I'm willing to make." / \ if you read it the right way. | -- Lord Farquaad (Shrek)
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 11:45 +0000 |
| Message-ID | <rt1jhk$cks$1@dont-email.me> |
| In reply to | #25447 |
On 04/01/2021 22:50, Dan Espen wrote: > Pancho <Pancho.Dontmaileme@outlook.com> writes: > >> Most compilers leave fingerprints on executables you don't need an AI >> to detect them. I remember decompiling in the early 80's but complex >> modern code can often be a challenge to naively reverse engineer a >> high level understanding from even if you do have source code. Take >> away sensible variable and function names and you are stuffed. > > I've had more than one experience in putting those meaningful variable > names right back. It's actually pretty easy, a somewhat rote process. > Find the read input instruction. Since you know the layout of the input > record, you now have labels to many of the references to that input > area. > > I think you can work out how to proceed. ISTR that my attack on the executable started by seeking out lines of code that might be subroutine calls, "JSR PC, address" in the PDP11 code. This served to create a number of identifiable and separate blocks from which to proceed. Of course, this was much easier as it was a stand-alone paper tape program with no operating system underneath to muddy the water.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-01-05 14:25 -0700 |
| Message-ID | <1120271503.631573805.041128.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #25466 |
gareth evans <headstone255@yahoo.com> wrote: > On 04/01/2021 22:50, Dan Espen wrote: >> Pancho <Pancho.Dontmaileme@outlook.com> writes: >> >>> Most compilers leave fingerprints on executables you don't need an AI >>> to detect them. I remember decompiling in the early 80's but complex >>> modern code can often be a challenge to naively reverse engineer a >>> high level understanding from even if you do have source code. Take >>> away sensible variable and function names and you are stuffed. >> >> I've had more than one experience in putting those meaningful variable >> names right back. It's actually pretty easy, a somewhat rote process. >> Find the read input instruction. Since you know the layout of the input >> record, you now have labels to many of the references to that input >> area. >> >> I think you can work out how to proceed. > > ISTR that my attack on the executable started by seeking out lines > of code that might be subroutine calls, "JSR PC, address" in the > PDP11 code. This served to create a number of identifiable and > separate blocks from which to proceed. > > Of course, this was much easier as it was a stand-alone paper > tape program with no operating system underneath to muddy the > water. > Most architectures seem to be simpler than x86 with its mix of random instruction lengths. Start at almost any byte and a disassembler would probably be able to find a run of “instructions” that don’t make any sense when examined by a human. Disassemblers I have worked with allow for human input to mark constants, for example, and allow them to be skipped. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | J. Clarke <jclarke.873638@gmail.com> |
|---|---|
| Date | 2021-01-04 20:38 -0500 |
| Message-ID | <aag7vf5rm0mfmfthbkcfp60sm0g0ks7hie@4ax.com> |
| In reply to | #25445 |
On Mon, 4 Jan 2021 21:57:32 +0000, Pancho <Pancho.Dontmaileme@outlook.com> wrote: >On 04/01/2021 17:51, gareth evans wrote: >> On 04/01/2021 13:08, Pancho wrote: >>> On 04/01/2021 11:00, gareth evans wrote: >>>> Thinking back to my first job, nearly 50 years ago now, >>>> when I had to dis-assemble DEC's paper tape BASIC >>>> interpreter in order to enhance it, I guess that >>>> dis-assemblers and decompilers must now be ten-a-penny, >>>> especially for programs running under Windows where >>>> the structure of Windows programs is well-known with >>>> an assumption that C was the source language? >>>> >>>> But I wonder if Artificial Intelligence could, after >>>> being fed with numerous instruction sets, take a >>>> block of binary, and analyse its source without >>>> any prior knowledge of the instruction set? >>>> >>>> I am particularly interested in the Binary Blob >>>> provided for Raspberry Pi computers, with a view to >>>> getting detailed knowledge of the video processors >>>> employed therein. >>>> >>> I think a lot of the problem is defining the question. >>> >>> What do you want it to do? >>> >> >> I don't want it to do anything. I want to play at a low level >> with the thing ... large oaks from little acorns grow. >> > >Play with what thing? The pieces of the hardware supported by the Blob. >What is an instruction set, The list of binary codes that tell the procesor what to do. >what is the Binary Blob? On the Raspberry Pi it is the non-Open-Source proprietary code that is provided by the chip manufacturer, including parts of the boot loader and the 3D drivers among other things. >Why do you need an AI? Why not? >Most compilers leave fingerprints on executables you don't need an AI to >detect them. I remember decompiling in the early 80's but complex modern >code can often be a challenge to naively reverse engineer a high level >understanding from even if you do have source code. Take away sensible >variable and function names and you are stuffed. He's talking about something that you can give a pile of object code from an unknown source (I mean _really_ unknown--it could be for Z/OS or a VAX or Intel or Alpha or any other architecture, compiled from C or PL/I or Fortran or pick a language at random, with it figuring from there what the code does.
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 11:54 +0000 |
| Message-ID | <rt1k1d$fu8$1@dont-email.me> |
| In reply to | #25453 |
On 05/01/2021 01:38, J. Clarke wrote: > > He's talking about something that you can give a pile of object code > from an unknown source (I mean _really_ unknown--it could be for Z/OS > or a VAX or Intel or Alpha or any other architecture, compiled from C > or PL/I or Fortran or pick a language at random, with it figuring from > there what the code does. > Indeed! I've discussed this before (And probably too often according to my biographers and stalkers! but I'm interested in computers for themselves, as wonderful complex machines, and not interested in what you can use them for. My frustration lies with the Raspberry Pi series that come, for very little outlay of pennies, with a multi processor graphics chip which is believed to exceed the capabilities of the associated ARM processor but about which no detailed information is forthcoming.
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2021-01-05 14:06 -0700 |
| Message-ID | <1749007502.631567591.246155.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #25453 |
J. Clarke <jclarke.873638@gmail.com> wrote: > On Mon, 4 Jan 2021 21:57:32 +0000, Pancho > <Pancho.Dontmaileme@outlook.com> wrote: > >> On 04/01/2021 17:51, gareth evans wrote: >>> On 04/01/2021 13:08, Pancho wrote: >>>> On 04/01/2021 11:00, gareth evans wrote: >>>>> Thinking back to my first job, nearly 50 years ago now, >>>>> when I had to dis-assemble DEC's paper tape BASIC >>>>> interpreter in order to enhance it, I guess that >>>>> dis-assemblers and decompilers must now be ten-a-penny, >>>>> especially for programs running under Windows where >>>>> the structure of Windows programs is well-known with >>>>> an assumption that C was the source language? >>>>> >>>>> But I wonder if Artificial Intelligence could, after >>>>> being fed with numerous instruction sets, take a >>>>> block of binary, and analyse its source without >>>>> any prior knowledge of the instruction set? >>>>> >>>>> I am particularly interested in the Binary Blob >>>>> provided for Raspberry Pi computers, with a view to >>>>> getting detailed knowledge of the video processors >>>>> employed therein. >>>>> >>>> I think a lot of the problem is defining the question. >>>> >>>> What do you want it to do? >>>> >>> >>> I don't want it to do anything. I want to play at a low level >>> with the thing ... large oaks from little acorns grow. >>> >> >> Play with what thing? > > The pieces of the hardware supported by the Blob. > >> What is an instruction set, > > The list of binary codes that tell the procesor what to do. > >> what is the Binary Blob? > > On the Raspberry Pi it is the non-Open-Source proprietary code that is > provided by the chip manufacturer, including parts of the boot loader > and the 3D drivers among other things. > >> Why do you need an AI? > > Why not? > >> Most compilers leave fingerprints on executables you don't need an AI to >> detect them. I remember decompiling in the early 80's but complex modern >> code can often be a challenge to naively reverse engineer a high level >> understanding from even if you do have source code. Take away sensible >> variable and function names and you are stuffed. > > He's talking about something that you can give a pile of object code > from an unknown source (I mean _really_ unknown--it could be for Z/OS > or a VAX or Intel or Alpha or any other architecture, compiled from C > or PL/I or Fortran or pick a language at random, with it figuring from > there what the code does. > The object code format would give you a clue, at least for most mainstream architectures. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 22:52 +0000 |
| Message-ID | <rt2qjt$h9p$2@dont-email.me> |
| In reply to | #25501 |
On 05/01/2021 21:06, Peter Flass wrote: > J. Clarke <jclarke.873638@gmail.com> wrote: >> On Mon, 4 Jan 2021 21:57:32 +0000, Pancho >> <Pancho.Dontmaileme@outlook.com> wrote: >> >>> On 04/01/2021 17:51, gareth evans wrote: >>>> On 04/01/2021 13:08, Pancho wrote: >>>>> On 04/01/2021 11:00, gareth evans wrote: >>>>>> Thinking back to my first job, nearly 50 years ago now, >>>>>> when I had to dis-assemble DEC's paper tape BASIC >>>>>> interpreter in order to enhance it, I guess that >>>>>> dis-assemblers and decompilers must now be ten-a-penny, >>>>>> especially for programs running under Windows where >>>>>> the structure of Windows programs is well-known with >>>>>> an assumption that C was the source language? >>>>>> >>>>>> But I wonder if Artificial Intelligence could, after >>>>>> being fed with numerous instruction sets, take a >>>>>> block of binary, and analyse its source without >>>>>> any prior knowledge of the instruction set? >>>>>> >>>>>> I am particularly interested in the Binary Blob >>>>>> provided for Raspberry Pi computers, with a view to >>>>>> getting detailed knowledge of the video processors >>>>>> employed therein. >>>>>> >>>>> I think a lot of the problem is defining the question. >>>>> >>>>> What do you want it to do? >>>>> >>>> >>>> I don't want it to do anything. I want to play at a low level >>>> with the thing ... large oaks from little acorns grow. >>>> >>> >>> Play with what thing? >> >> The pieces of the hardware supported by the Blob. >> >>> What is an instruction set, >> >> The list of binary codes that tell the procesor what to do. >> >>> what is the Binary Blob? >> >> On the Raspberry Pi it is the non-Open-Source proprietary code that is >> provided by the chip manufacturer, including parts of the boot loader >> and the 3D drivers among other things. >> >>> Why do you need an AI? >> >> Why not? >> >>> Most compilers leave fingerprints on executables you don't need an AI to >>> detect them. I remember decompiling in the early 80's but complex modern >>> code can often be a challenge to naively reverse engineer a high level >>> understanding from even if you do have source code. Take away sensible >>> variable and function names and you are stuffed. >> >> He's talking about something that you can give a pile of object code >> from an unknown source (I mean _really_ unknown--it could be for Z/OS >> or a VAX or Intel or Alpha or any other architecture, compiled from C >> or PL/I or Fortran or pick a language at random, with it figuring from >> there what the code does. >> > > The object code format would give you a clue, at least for most mainstream > architectures. > In the case of the RPi GPU the format is completley unknown.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2021-01-05 10:29 +0000 |
| Message-ID | <rt1f1o$d1f$2@dont-email.me> |
| In reply to | #25445 |
On 04/01/2021 21:57, Pancho wrote:
> Most compilers leave fingerprints on executables you don't need an AI to
> detect them. I remember decompiling in the early 80's but complex modern
> code can often be a challenge to naively reverse engineer a high level
> understanding from even if you do have source code. Take away sensible
> variable and function names and you are stuffed.
+1001
--
"First, find out who are the people you can not criticise. They are your
oppressors."
- George Orwell
[toc] | [prev] | [next] | [standalone]
| From | Dennis Lee Bieber <wlfraed@ix.netcom.com> |
|---|---|
| Date | 2021-01-04 11:05 -0500 |
| Message-ID | <51f6vf56b3eeacskirm9b54sr7kuf8s1pl@4ax.com> |
| In reply to | #25425 |
On Mon, 4 Jan 2021 11:00:29 +0000, gareth evans <headstone255@yahoo.com> declaimed the following: >Thinking back to my first job, nearly 50 years ago now, >when I had to dis-assemble DEC's paper tape BASIC >interpreter in order to enhance it, I guess that >dis-assemblers and decompilers must now be ten-a-penny, >especially for programs running under Windows where >the structure of Windows programs is well-known with >an assumption that C was the source language? > Actually, I think the use of disassemblers et al has fallen away. Modern processors have so many peephole optimizations and out-of-order execution streams that converting an executable back to assembly source is almost meaningless -- and getting back to a high-level language is near impossible. One would have to be an expert at the assembly for a processor to have any chance of understanding the result. -- Wulfraed Dennis Lee Bieber AF6VN wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-04 17:07 +0000 |
| Message-ID | <rsvi0n$epp$7@dont-email.me> |
| In reply to | #25436 |
On Mon, 04 Jan 2021 11:05:55 -0500, Dennis Lee Bieber wrote: > On Mon, 4 Jan 2021 11:00:29 +0000, gareth evans <headstone255@yahoo.com> > declaimed the following: > >>Thinking back to my first job, nearly 50 years ago now, >>when I had to dis-assemble DEC's paper tape BASIC interpreter in order >>to enhance it, I guess that dis-assemblers and decompilers must now be >>ten-a-penny, >>especially for programs running under Windows where the structure of >>Windows programs is well-known with an assumption that C was the source >>language? >> > Actually, I think the use of disassemblers et al has fallen away. > Modern processors have so many peephole optimizations and out-of-order > execution streams that converting an executable back to assembly source > is almost meaningless -- and getting back to a high-level language is > near impossible. One would have to be an expert at the assembly for a > processor to have any chance of understanding the result. The retro-computing guys - those who are fans of the MC6800 and MC6809 microprocessors anyway, anyway, seem to be getting a rather good semi- interactive disassembler up and running. So far it understands executables that run under FLEX, FLEX09 for both 6800 and 6809 and under UniFlex and OS9/level 1 and 2 on a 6809 and can automatically detect which OS the binary was compiled for. This is quite impressive, since all four OSen have very different API call structures despite FLEX09,UniFlex and OS/9 all running on the same chip. -- -- Martin | martin at Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2021-01-04 17:52 +0000 |
| Message-ID | <zBIIH.63573$1X1.11761@fx05.iad> |
| In reply to | #25437 |
Martin Gregorie <martin@mydomain.invalid> writes: >On Mon, 04 Jan 2021 11:05:55 -0500, Dennis Lee Bieber wrote: > >> On Mon, 4 Jan 2021 11:00:29 +0000, gareth evans <headstone255@yahoo.com> >> declaimed the following: >> >>>Thinking back to my first job, nearly 50 years ago now, >>>when I had to dis-assemble DEC's paper tape BASIC interpreter in order >>>to enhance it, I guess that dis-assemblers and decompilers must now be >>>ten-a-penny, >>>especially for programs running under Windows where the structure of >>>Windows programs is well-known with an assumption that C was the source >>>language? >>> >> Actually, I think the use of disassemblers et al has fallen away. >> Modern processors have so many peephole optimizations and out-of-order >> execution streams that converting an executable back to assembly source >> is almost meaningless -- and getting back to a high-level language is >> near impossible. One would have to be an expert at the assembly for a >> processor to have any chance of understanding the result. > >The retro-computing guys - those who are fans of the MC6800 and MC6809 >microprocessors anyway, anyway, seem to be getting a rather good semi- >interactive disassembler up and running. Security experts have several very powerful disassemblers and decompilers they use for Intel/AMD/ARM processors. https://en.wikibooks.org/wiki/X86_Disassembly/Disassemblers_and_Decompilers
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2021-01-05 10:28 +0000 |
| Message-ID | <rt1f0b$d1f$1@dont-email.me> |
| In reply to | #25441 |
On 04/01/2021 17:52, Scott Lurndal wrote:
> Martin Gregorie <martin@mydomain.invalid> writes:
>> On Mon, 04 Jan 2021 11:05:55 -0500, Dennis Lee Bieber wrote:
>>
>>> On Mon, 4 Jan 2021 11:00:29 +0000, gareth evans <headstone255@yahoo.com>
>>> declaimed the following:
>>>
>>>> Thinking back to my first job, nearly 50 years ago now,
>>>> when I had to dis-assemble DEC's paper tape BASIC interpreter in order
>>>> to enhance it, I guess that dis-assemblers and decompilers must now be
>>>> ten-a-penny,
>>>> especially for programs running under Windows where the structure of
>>>> Windows programs is well-known with an assumption that C was the source
>>>> language?
>>>>
>>> Actually, I think the use of disassemblers et al has fallen away.
>>> Modern processors have so many peephole optimizations and out-of-order
>>> execution streams that converting an executable back to assembly source
>>> is almost meaningless -- and getting back to a high-level language is
>>> near impossible. One would have to be an expert at the assembly for a
>>> processor to have any chance of understanding the result.
>>
>> The retro-computing guys - those who are fans of the MC6800 and MC6809
>> microprocessors anyway, anyway, seem to be getting a rather good semi-
>> interactive disassembler up and running.
>
> Security experts have several very powerful disassemblers and decompilers
> they use for Intel/AMD/ARM processors.
>
> https://en.wikibooks.org/wiki/X86_Disassembly/Disassemblers_and_Decompilers
>
Yes. I am certain that certain compilers and certain languages leave a
fingerprint, Always THAT resister, used to do THAT job, always that
particular sequence of assembly to mimic that high level construct.
I cut my teeth on microprocessor assembly. The C. Some things that are
neat in assembler are ugly as sin in C. Take a call table. In assembler,
you set up a range of memory whose contents contain the addresses of
subroutines. You load the accumulator with a number, left shift it once,
add it to the content of a register set to point to the base of that
memory block, and use that register as pointing to an address whose
contents are the address you want to 'call' Simple, efficient and
provided you ensure nothing out of bounds is in the accumulator, bomb proof.
Now try that in C, you need an array of pointers to functions, and a
simple check on the index you engage, followed by a declaration to call
the function whose address is in the array of pointers to functions. I
never ever managed to get an 8 bit compiler to actually do that. People
just don't call the contents of an array of pointers to functions.
Its easier by far to set up a switch statement, which takes care of out
of bounds defaults, and ends up producing a chain of if..else if.. else
conditional calls to hardwired functions.
That's how you write it, because its pretty much as fast on a pipelined
processor, RAM is cheap and comprehensibility beats programming elegance
hands down in the real world.
I've examined a lot of compiled machine code and its pretty easy to tell
what language it is, and what roughly it was written as. Stack based
variables is a bit of a give away pointing to C or a similar langauge.
highly optimised compilers of course automatically obfuscate things, but
that's the fun isn't it?
I gave up writing assembler for *86 CPUs when the Gnu compiler was
patently doing a better job than I would in assembler, and the ability
to write something long winded and easy to understand and have the
compiler completely rearrange it and turn it into three lines of
incomprehensible assembler, was to be respected.
I think it is up to a limited point entirely possible to make an AI that
could replace machine code with editable and compilable source code.
But there will always be the Problem Of Induction. Many many possible
constructs in source using an infinite number of random variable and
function names, could compile to the same object code. And there is no
way to reinstate the comments either, so it becomes an exercise
ultimately in hand editing and reinstating the comments manually -
almost as big a job as writing from scratch.
I suspect this is how Linux writers write freeware drivers for
proprietary hardware. Disassemble the manufacturers drivers, and at
least mimic the program flow, if not the actual source code.
--
“I know that most men, including those at ease with problems of the
greatest complexity, can seldom accept even the simplest and most
obvious truth if it be such as would oblige them to admit the falsity of
conclusions which they have delighted in explaining to colleagues, which
they have proudly taught to others, and which they have woven, thread by
thread, into the fabric of their lives.”
― Leo Tolstoy
[toc] | [prev] | [next] | [standalone]
| From | Thomas Koenig <tkoenig@netcologne.de> |
|---|---|
| Date | 2021-01-05 13:06 +0000 |
| Message-ID | <rt1o94$t0i$1@newsreader4.netcologne.de> |
| In reply to | #25460 |
The Natural Philosopher <tnp@invalid.invalid> schrieb:
> The C. Some things that are
> neat in assembler are ugly as sin in C.
One thing that is hard to do with C is to have different entries
to the same function, something like:
bar:
.cfi_startproc
... do something
foo:
... do something else
ret
and then either call foo or bar.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2021-01-05 13:41 +0000 |
| Message-ID | <rt1q9r$siv$1@dont-email.me> |
| In reply to | #25474 |
On 05/01/2021 13:06, Thomas Koenig wrote:
> The Natural Philosopher <tnp@invalid.invalid> schrieb:
>> The C. Some things that are
>> neat in assembler are ugly as sin in C.
>
> One thing that is hard to do with C is to have different entries
> to the same function, something like:
>
> bar:
> .cfi_startproc
> ... do something
> foo:
> ... do something else
>
> ret
>
> and then either call foo or bar.
>
Indeed.
I had to write an extended but of assemble once to fit in 2K eprom - a
bios for larger disks using larger sectors than standard msdos.
I was frustratingly about 80 bytes short.
I looked at the code for a long time trying to think what I could use in
various places - and found something.
The original cider was always in the habit of using the same two
register - AX and BX, as scratch, (Sometimes he used DX as well)
so every subroutine started with push AX, PUSH BX, and ended with POP
BX, POP AX, RET. Sometimes he used DX as well
that was three words or four . But JMP MY_EXIT (or DX_EXIT)was only two...
DX_EXIT: POP DX
MY_EXIT: POP BX
POP AX
RET
But that is exactly the sort of things a compiler optimised for code
size rather than speed, would be expected to do. Find common bits of
code and jump to them
--
Climate Change: Socialism wearing a lab coat.
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 15:30 +0000 |
| Message-ID | <rt20m1$b2q$1@dont-email.me> |
| In reply to | #25474 |
On 05/01/2021 13:06, Thomas Koenig wrote: > The Natural Philosopher <tnp@invalid.invalid> schrieb: >> The C. Some things that are >> neat in assembler are ugly as sin in C. > > One thing that is hard to do with C is to have different entries > to the same function, something like: > > bar: > .cfi_startproc > ... do something > foo: > ... do something else > > ret > > and then either call foo or bar. > Blimey, that takes me back over 40 years to a neat trick of mine to save a couple of bytes (but something today that might get you the sack in these times of the high cost of software maintenance!). It's a way of passing on the stack a zero / non zero value. In PDP11 (Octal!!!!!!!) opcodes .. 012746 5046 the first word says Push the value 5046 onto the stack, but the second word, 5046 means clear the next stack entry. So, by jumping to the second word of the instruction, you push a zero value! That it warrants such an involved explanation is very good reason why such techniques should be avoided today! :-)
[toc] | [prev] | [next] | [standalone]
| From | Martin Gregorie <martin@mydomain.invalid> |
|---|---|
| Date | 2021-01-05 16:42 +0000 |
| Message-ID | <rt24uh$cqo$2@dont-email.me> |
| In reply to | #25486 |
On Tue, 05 Jan 2021 15:30:06 +0000, gareth evans wrote: > That it warrants such an involved explanation is very good reason why > such techniques should be avoided today! :-) Agreed. That sort of thing is so much easier in Java or Algol 68, which both recognise that methods/procedures with the same name but different parameter lists are indeed different pieces of code rather than a stupid mistake. -- -- Martin | martin at Gregorie | gregorie dot org
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2021-01-05 20:12 +0000 |
| Message-ID | <rt2h7p4sc8@news2.newsguy.com> |
| In reply to | #25492 |
On 2021-01-05, Martin Gregorie <martin@mydomain.invalid> wrote: > On Tue, 05 Jan 2021 15:30:06 +0000, gareth evans wrote: > >> That it warrants such an involved explanation is very good reason why >> such techniques should be avoided today! :-) > > Agreed. > > That sort of thing is so much easier in Java or Algol 68, which both > recognise that methods/procedures with the same name but different > parameter lists are indeed different pieces of code rather than a stupid > mistake. I avoid that technique - it invites other stupid mistakes. -- /~\ Charlie Gibbs | "Some of you may die, \ / <cgibbs@kltpzyxm.invalid> | but it's a sacrifice X I'm really at ac.dekanfrus | I'm willing to make." / \ if you read it the right way. | -- Lord Farquaad (Shrek)
[toc] | [prev] | [next] | [standalone]
| From | gareth evans <headstone255@yahoo.com> |
|---|---|
| Date | 2021-01-05 20:20 +0000 |
| Message-ID | <rt2hme$hkf$1@dont-email.me> |
| In reply to | #25497 |
On 05/01/2021 20:12, Charlie Gibbs wrote: > On 2021-01-05, Martin Gregorie <martin@mydomain.invalid> wrote: > >> On Tue, 05 Jan 2021 15:30:06 +0000, gareth evans wrote: >> >>> That it warrants such an involved explanation is very good reason why >>> such techniques should be avoided today! :-) >> >> Agreed. >> >> That sort of thing is so much easier in Java or Algol 68, which both >> recognise that methods/procedures with the same name but different >> parameter lists are indeed different pieces of code rather than a stupid >> mistake. > > I avoid that technique - it invites other stupid mistakes. > +1 Why any coder would want a procname with different calling lists is beyond me. To object to having x_procname and y_procname etc suggests a coder is not focussed on the matter in hand but is religiously adhering to some irrelevant convention.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.sys.raspberry-pi
csiph-web