Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > alt.folklore.computers > #159496 > unrolled thread
| Started by | "Osmium" <r124c4u102@comcast.net> |
|---|---|
| First post | 2016-02-16 10:37 -0600 |
| Last post | 2016-02-19 12:55 -0600 |
| Articles | 20 on this page of 317 — 37 participants |
Back to article view | Back to alt.folklore.computers
Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-16 10:37 -0600
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-16 09:54 -0800
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-16 19:41 +0100
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-16 21:11 +0100
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-17 02:16 +0100
Re: Ransomware usenet@only.tnx (Questor) - 2016-02-17 22:05 +0000
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-17 23:35 +0100
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-18 13:58 +0000
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-17 18:41 -0700
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-16 18:52 -0700
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-17 14:13 +1100
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-17 04:53 +0100
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-17 04:21 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-17 17:24 +1100
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-17 15:07 +0100
Re: Ransomware usenet@only.tnx (Questor) - 2016-02-17 23:02 +0000
Re: Ransomware Huge <Huge@nowhere.much.invalid> - 2016-02-17 08:03 +0000
Re: Ransomware usenet@only.tnx (Questor) - 2016-02-17 23:02 +0000
Re: Ransomware Huge <Huge@nowhere.much.invalid> - 2016-02-17 08:01 +0000
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-17 18:07 +0000
Re: Ransomware Walter Banks <walter@bytecraft.com> - 2016-02-17 14:01 -0500
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-17 18:41 -0700
Re: Ransomware Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-17 18:09 -0800
Re: Ransomware Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-02-17 20:45 -0700
Re: Ransomware Jon Elson <elson@pico-systems.com> - 2016-02-17 22:34 -0600
Re: Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-18 11:16 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-19 05:44 +1100
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-18 15:00 +1100
Re: Ransomware Roger Blake <rogblake@iname.invalid> - 2016-02-18 02:12 +0000
Re: Ransomware Dan Espen <despen@verizon.net> - 2016-02-17 22:47 -0500
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-18 15:10 +1100
Re: Ransomware Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-17 21:29 -0800
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-18 17:56 +1100
Re: Ransomware Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-17 23:15 -0800
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-18 18:35 +1100
Re: Ransomware Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-18 17:58 -0800
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-19 13:44 +1100
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-17 20:44 -0800
Re: Ransomware Lawrence Statton <lawrence@senguio.mx> - 2016-02-18 08:03 -0600
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-18 17:14 -0600
Re: Ransomware Lawrence Statton <lawrence@senguio.mx> - 2016-02-18 19:10 -0600
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-18 20:13 -0800
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-19 15:26 +1100
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-19 09:34 -0600
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-19 16:26 +0000
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-19 14:58 -0600
Re: Ransomware Dan Espen <despen@verizon.net> - 2016-02-19 18:21 -0500
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-19 18:43 -0700
Re: Ransomware Dan Espen <despen@verizon.net> - 2016-02-19 23:32 -0500
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-19 19:34 -0800
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 19:59 +1100
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-20 07:25 -0500
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-20 10:30 -0600
Re: Ransomware Dave Garland <dave.garland@wizinfo.com> - 2016-02-20 10:58 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 04:25 +1100
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-20 19:56 +0000
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-20 18:15 -0700
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 13:26 +1100
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 04:16 +1100
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-20 18:15 -0700
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 13:22 +1100
Re: Ransomware Walter Banks <walter@bytecraft.com> - 2016-02-19 17:36 -0500
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 10:01 +1100
Re: Ransomware Gene Wirchenko <genew@telus.net> - 2016-02-20 16:26 -0800
Re: Ransomware Gene Wirchenko <genew@telus.net> - 2016-02-21 13:52 -0800
Re: Ransomware Walter Banks <walter@bytecraft.com> - 2016-02-21 18:51 -0500
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-19 19:18 -0800
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 15:03 +1100
Re: Ransomware Andrew Swallow <am.swallow@btinternet.com> - 2016-02-20 16:12 +0000
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-19 15:59 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 09:59 +1100
Re: Ransomware Dave Garland <dave.garland@wizinfo.com> - 2016-02-19 18:43 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 14:36 +1100
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-19 17:01 -0600
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-19 18:54 -0600
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-19 19:48 -0600
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-20 16:20 -0600
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-20 18:17 -0600
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-19 19:53 -0800
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-19 18:43 -0700
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-19 21:33 -0500
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-20 10:23 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 14:48 +1100
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-19 19:56 -0800
Re: Ransomware Michael Black <et472@ncf.ca> - 2016-02-19 23:18 -0500
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-20 10:35 -0600
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-20 10:12 -0600
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-20 15:33 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 12:11 +1100
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-19 18:43 -0700
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-19 20:00 -0800
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-20 01:51 -0700
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-20 10:34 -0600
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-20 10:19 -0600
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-19 19:40 -0800
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 03:46 +1100
Re: Ransomware Dave Garland <dave.garland@wizinfo.com> - 2016-02-18 23:55 -0600
Re: Ransomware mausg@mail.com - 2016-02-19 10:48 +0000
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-19 05:56 -0500
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-19 09:50 -0600
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-19 16:29 +0000
Re: Ransomware Stan Barr <plan.b@bluesomatic.org> - 2016-02-19 16:54 +0000
Re: Ransomware Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-19 17:55 +0000
Re: Ransomware Stan Barr <plan.b@bluesomatic.org> - 2016-02-20 08:30 +0000
Re: Ransomware Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-20 15:29 +0000
Re: Ransomware Lawrence Statton NK1G <lawrence@senguio.mx> - 2016-02-20 10:06 -0600
Re: Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-20 11:03 -0600
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 16:14 -0600
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 16:27 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-23 09:49 +1100
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 05:29 +1100
Re: Ransomware Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-19 18:53 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 09:42 +1100
Re: Ransomware Walter Banks <walter@bytecraft.com> - 2016-02-19 14:24 -0500
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-19 14:58 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 05:24 +1100
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 04:53 +1100
Re: Ransomware Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-19 18:15 +0000
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-19 17:55 -0800
Re: Ransomware Walter Banks <walter@bytecraft.com> - 2016-02-18 11:19 -0500
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-18 10:19 -0600
Re: Ransomware Walter Banks <walter@bytecraft.com> - 2016-02-18 11:46 -0500
Re: Ransomware Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-18 18:01 +0000
Re: Ransomware Walter Banks <walter@bytecraft.com> - 2016-02-18 14:36 -0500
Re: Ransomware Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-19 11:23 +0000
Re: Ransomware Walter Banks <walter@bytecraft.com> - 2016-02-19 09:28 -0500
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 05:19 +1100
Re: Ransomware Dave Garland <dave.garland@wizinfo.com> - 2016-02-18 11:06 -0600
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-18 10:24 -0700
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-18 12:27 -0800
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-19 10:22 +1100
Re: Ransomware Dave Garland <dave.garland@wizinfo.com> - 2016-02-19 00:07 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-19 18:34 +1100
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-19 05:41 -0500
Re: Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-19 07:43 -0600
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-19 16:13 +0000
Re: Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-19 08:01 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 04:50 +1100
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-18 21:34 +0000
Re: Ransomware Lawrence Statton <lawrence@senguio.mx> - 2016-02-18 13:34 -0600
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 17:34 -0500
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-19 10:33 +1100
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 21:04 -0500
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-19 13:46 +1100
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-19 05:34 -0500
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 04:47 +1100
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-19 14:24 +0000
Re: Ransomware Walter Banks <walter@bytecraft.com> - 2016-02-18 11:03 -0500
Re: Ransomware Ibmekon <Ibmekon> - 2016-02-18 19:21 +0000
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-18 20:56 +0000
Re: Ransomware Ibmekon <Ibmekon> - 2016-02-18 21:19 +0000
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-19 13:48 +0000
Re: Ransomware Ibmekon <Ibmekon> - 2016-02-19 14:12 +0000
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-19 09:54 -0600
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 03:29 +1100
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-20 10:42 -0600
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-21 15:48 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-22 03:43 +1100
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-21 12:55 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-22 07:53 +1100
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-23 13:13 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-24 04:49 +1100
Re: Ransomware Ibmekon <Ibmekon> - 2016-02-21 19:56 +0000
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-19 16:19 +0000
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-19 18:08 -0800
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-19 18:18 -0800
Re: Ransomware mausg@mail.com - 2016-02-19 18:10 +0000
Re: Ransomware Ibmekon <Ibmekon> - 2016-02-19 21:43 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 09:52 +1100
Re: Ransomware Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-19 16:53 -0800
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-18 18:37 -0600
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-18 13:58 +0000
Re: Ransomware "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-19 05:32 +1100
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-17 11:13 -0600
Re: Ransomware Roger Blake <rogblake@iname.invalid> - 2016-02-16 17:57 +0000
Re: Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-16 14:19 -0600
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-17 03:42 +0000
Re: Ransomware Huge <Huge@nowhere.much.invalid> - 2016-02-17 08:05 +0000
Re: Ransomware Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-17 12:03 +0000
Re: Ransomware Morten Reistad <first@last.name,invalid> - 2016-02-17 15:21 +0100
Re: Ransomware Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-02-17 07:38 -0700
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-17 18:07 +0000
Re: Ransomware "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-18 12:10 -0600
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-18 21:34 +0000
Re: Ransomware "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-18 12:06 -0600
Re: Ransomware Quadibloc <jsavard@ecn.ab.ca> - 2016-02-16 12:49 -0800
Re: Ransomware Lawrence Statton <lawrence@senguio.mx> - 2016-02-16 16:55 -0600
Re: Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-16 17:31 -0600
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-16 16:11 -0800
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-17 14:26 +1100
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-17 11:19 -0600
Re: Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-17 12:05 -0600
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-17 17:58 -0600
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-17 18:41 -0700
Re: Ransomware Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-17 18:39 -0800
Re: Ransomware Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-02-16 16:44 -0400
Re: Ransomware Jon Elson <jmelson@wustl.edu> - 2016-02-16 15:30 -0600
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-17 00:20 +0100
Re: Ransomware usenet@only.tnx (Questor) - 2016-02-17 23:03 +0000
Re: Ransomware Michael Black <et472@ncf.ca> - 2016-02-17 18:48 -0500
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-18 13:58 +0000
Re: Ransomware Morten Reistad <first@Last.name.invalid> - 2016-02-18 16:46 +0100
Re: Ransomware Gene Wirchenko <genew@telus.net> - 2016-02-18 11:06 -0800
Re: Ransomware Dan Espen <despen@verizon.net> - 2016-02-18 14:43 -0500
Re: Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-18 14:06 -0600
Re: Ransomware Dan Espen <despen@verizon.net> - 2016-02-18 15:48 -0500
Re: Ransomware "Osmium" <r124c4u102@comcast.net> - 2016-02-18 15:36 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-19 10:30 +1100
Re: Ransomware Dan Espen <despen@verizon.net> - 2016-02-18 19:38 -0500
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-18 21:43 +0000
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-19 00:51 +0100
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-19 13:45 +0000
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-19 15:00 +0100
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-19 07:01 -0700
Re: Ransomware Dan Espen <despen@verizon.net> - 2016-02-19 10:16 -0500
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-19 11:15 -0700
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-19 11:19 -0700
Re: Ransomware Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-19 18:55 +0000
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-19 12:54 -0700
Re: Ransomware Gene Wirchenko <genew@telus.net> - 2016-02-20 17:46 -0800
Re: Ransomware JimP <solosam90@gmail.com> - 2016-02-19 15:08 -0600
Re: Ransomware "Charles Richmond" <numerist@aquaporin4.com> - 2016-02-23 16:01 -0600
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-23 21:24 -0500
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-20 04:58 +1100
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-19 13:40 +0000
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-19 14:24 +0000
Re: Ransomware "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-20 05:06 +1100
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-19 10:11 +1100
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-18 21:44 +0100
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-19 14:24 +0000
Re: Ransomware "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-20 05:13 +1100
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-19 14:24 +0000
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-19 17:08 +0100
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 03:41 +1100
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-20 18:15 -0700
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-21 09:35 +0100
Re: Ransomware Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-21 10:18 +0000
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-21 16:48 +0100
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-21 18:40 -0600
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-22 01:53 +0100
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-21 18:36 -0700
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 00:12 -0600
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-22 09:37 +0100
Re: Ransomware Dan Espen <despen@verizon.net> - 2016-02-22 09:17 -0500
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-22 15:29 +0100
Re: Ransomware using libc Dan Espen <despen@verizon.net> - 2016-02-22 09:42 -0500
Re: Ransomware using libc Melzzzzz <mel@zzzzz.com> - 2016-02-22 15:52 +0100
Re: Ransomware using libc Dan Espen <despen@verizon.net> - 2016-02-22 10:23 -0500
Re: Ransomware using libc scott@slp53.sl.home (Scott Lurndal) - 2016-02-22 17:24 +0000
Re: Ransomware using libc Melzzzzz <mel@zzzzz.com> - 2016-02-22 20:29 +0100
Re: Ransomware using libc Ahem A Rivet's Shot <steveo@eircom.net> - 2016-02-22 19:38 +0000
Re: Ransomware using libc Melzzzzz <mel@zzzzz.com> - 2016-02-22 21:31 +0100
Re: Ransomware using libc Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-22 17:17 +0000
Re: Ransomware using libc Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 14:41 -0600
Re: Ransomware using libc Melzzzzz <mel@zzzzz.com> - 2016-02-22 22:07 +0100
Re: Ransomware Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-02-22 09:16 -0700
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-22 17:21 +0100
Re: Ransomware Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-02-22 09:34 -0700
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 11:11 -0600
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-22 18:25 +0100
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 15:15 -0600
Re: Ransomware Melzzzzz <mel@zzzzz.com> - 2016-02-22 22:28 +0100
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-22 21:46 -0600
Re: Ransomware "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-20 05:05 +1100
Re: Ransomware "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-19 05:31 +1100
Re: Ransomware Jon Elson <jmelson@wustl.edu> - 2016-02-18 13:56 -0600
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-19 14:24 +0000
Re: Ransomware "Rod Speed" <rod.speed.aaa@gmail.com> - 2016-02-20 05:16 +1100
Re: Ransomware Jon Elson <jmelson@wustl.edu> - 2016-02-19 17:09 -0600
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-20 15:18 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 03:55 +1100
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-20 19:56 +0000
Re: Ransomware Jon Elson <jmelson@wustl.edu> - 2016-02-22 14:07 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-23 07:15 +1100
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-22 18:30 -0500
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-23 01:49 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-23 13:09 +1100
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-23 13:03 +1100
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-19 13:12 -0600
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 06:29 -0500
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-19 13:35 -0600
Re: Ransomware Huge <Huge@nowhere.much.invalid> - 2016-02-20 09:55 +0000
Re: Ransomware Peter Flass <peter_flass@yahoo.com> - 2016-02-20 07:30 -0700
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-20 11:11 -0500
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-21 04:05 +1100
Re: Ransomware Huge <Huge@nowhere.much.invalid> - 2016-02-21 11:55 +0000
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-21 14:04 +0100
Re: Ransomware Huge <Huge@nowhere.much.invalid> - 2016-02-21 13:57 +0000
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-21 23:28 +0000
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-22 03:34 +1100
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-22 03:32 +1100
Re: Ransomware Dave Garland <dave.garland@wizinfo.com> - 2016-02-21 12:14 -0600
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-22 07:47 +1100
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-17 14:03 +0000
Re: Ransomware Jon Elson <jmelson@wustl.edu> - 2016-02-17 15:20 -0600
Re: Ransomware scott@slp53.sl.home (Scott Lurndal) - 2016-02-17 21:31 +0000
Re: Ransomware Stan Barr <plan.b@bluesomatic.org> - 2016-02-18 08:23 +0000
Re: Ransomware Jon Elson <elson@pico-systems.com> - 2016-02-18 11:42 -0600
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 06:23 -0500
Re: Ransomware Jon Elson <elson@pico-systems.com> - 2016-02-18 11:43 -0600
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 17:48 -0500
Re: Ransomware hancock4@bbs.cpcn.com - 2016-02-16 17:04 -0800
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-17 14:42 +1100
Re: Ransomware Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-02-17 04:17 +0000
Re: Ransomware Mike Spencer <mds@bogus.nodomain.nowhere> - 2016-02-17 04:08 -0400
Re: Ransomware usenet@only.tnx (Questor) - 2016-02-17 23:04 +0000
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 06:38 -0500
Re: Ransomware Morten Reistad <first@last.name.invalid> - 2016-02-18 13:38 +0100
Re: Ransomware "J. Clarke" <j.clarke.873638@gmail.com> - 2016-02-18 17:57 -0500
Re: Ransomware "hgww" <hgww@gmail.com> - 2016-02-17 14:24 +1100
Re: Ransomware usenet@only.tnx (Questor) - 2016-02-17 23:03 +0000
Re: Ransomware Anne & Lynn Wheeler <lynn@garlic.com> - 2016-02-17 16:43 -0800
Re: Ransomware jmfbahciv <See.above@aol.com> - 2016-02-18 13:58 +0000
Re: Ransomware Stephen Sprunk <stephen@sprunk.org> - 2016-02-19 12:55 -0600
Page 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
| From | Morten Reistad <first@last.name.invalid> |
|---|---|
| Date | 2016-02-21 16:48 +0100 |
| Message-ID | <br2ppc-rec.ln1@sambook.reistad.name> |
| In reply to | #160028 |
In article <20160221101817.c9e898bd13bd2e7695735a1b@eircom.net>, Ahem A Rivet's Shot <steveo@eircom.net> wrote: >On Sat, 20 Feb 2016 18:15:39 -0700 >Peter Flass <peter_flass@yahoo.com> wrote: > >> What I haven't been able to find is a "bare metal" programming manual for >> Linux. Even the few Linux assembler books I've found assume use of >> libc. What I've found out I had to dig for. > > Unless you're writing kernel code there is no bare metal, the >lowest you get is the system calls - section 2 of the man pages should >document them fully. But why avoid libc ? Even in kernel space there's a >lot of library support you can count on. And the libc interface is the one that will remain stable. The OS calls may actually change between semi-major versions. Like the 32-64 bit move, when new calls came to be added, but some old ones actually had to change. Then the libc code had to be used to smooth over, so 32-bit calls still took 32-bit arguments and used 64-bit OS calls. This is one of the places where the OS-user mode interface looks almost directly taken from Tops20. The BSDs are quite different. -- mrr
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2016-02-21 18:40 -0600 |
| Message-ID | <nadl8m$l3o$1@dont-email.me> |
| In reply to | #159998 |
On 20-Feb-16 19:15, Peter Flass wrote: > jmfbahciv <See.above@aol.com> wrote: >> Morten Reistad wrote: >>> Go visit a good technical bookstore, and look at the *n*x shelf. >>> Or visit some oreilly.com or similar website. >> >> I have not looked in the last 5 years; I will try again. >> >> One of the reasons you cannot understand what I'm trying to talk >> about is because you already know too mych about Unix. Very few >> people can "play dumb" and be able to imagine what an inexperienced >> user needs. There may have been 4 or 5 people in all of DEC who >> could do this type of thinking. > > What I haven't been able to find is a "bare metal" programming manual > for Linux. Even the few Linux assembler books I've found assume use > of libc. What I've found out I had to dig for. The only thing below libc is syscalls, and those are subject to change without notice; the same application running on different systems--or even the same system after an upgrade--may require different syscalls, and libc makes all that completely transparent. Why would you want to involve yourself in that mess? Just call libc. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-02-22 01:53 +0100 |
| Message-ID | <20160222015341.17c9703b@maxa-pc> |
| In reply to | #160078 |
On Sun, 21 Feb 2016 18:40:40 -0600 Stephen Sprunk <stephen@sprunk.org> wrote: > On 20-Feb-16 19:15, Peter Flass wrote: > > jmfbahciv <See.above@aol.com> wrote: > >> Morten Reistad wrote: > >>> Go visit a good technical bookstore, and look at the *n*x shelf. > >>> Or visit some oreilly.com or similar website. > >> > >> I have not looked in the last 5 years; I will try again. > >> > >> One of the reasons you cannot understand what I'm trying to talk > >> about is because you already know too mych about Unix. Very few > >> people can "play dumb" and be able to imagine what an inexperienced > >> user needs. There may have been 4 or 5 people in all of DEC who > >> could do this type of thinking. > > > > What I haven't been able to find is a "bare metal" programming > > manual for Linux. Even the few Linux assembler books I've found > > assume use of libc. What I've found out I had to dig for. > > The only thing below libc is syscalls, and those are subject to change > without notice; the same application running on different systems--or > even the same system after an upgrade--may require different syscalls, > and libc makes all that completely transparent. > > Why would you want to involve yourself in that mess? Just call libc. > > S > I have yet to see code breakage from changed syscall ;) If you do assembler , you don't wont 500kb of libc bloat ...
[toc] | [prev] | [next] | [standalone]
| From | Peter Flass <peter_flass@yahoo.com> |
|---|---|
| Date | 2016-02-21 18:36 -0700 |
| Message-ID | <20186012.477797277.502717.peter_flass-yahoo.com@news.eternal-september.org> |
| In reply to | #160079 |
Melzzzzz <mel@zzzzz.com> wrote: > On Sun, 21 Feb 2016 18:40:40 -0600 > Stephen Sprunk <stephen@sprunk.org> wrote: > >> On 20-Feb-16 19:15, Peter Flass wrote: >>> jmfbahciv <See.above@aol.com> wrote: >>>> Morten Reistad wrote: >>>>> Go visit a good technical bookstore, and look at the *n*x shelf. >>>>> Or visit some oreilly.com or similar website. >>>> >>>> I have not looked in the last 5 years; I will try again. >>>> >>>> One of the reasons you cannot understand what I'm trying to talk >>>> about is because you already know too mych about Unix. Very few >>>> people can "play dumb" and be able to imagine what an inexperienced >>>> user needs. There may have been 4 or 5 people in all of DEC who >>>> could do this type of thinking. >>> >>> What I haven't been able to find is a "bare metal" programming >>> manual for Linux. Even the few Linux assembler books I've found >>> assume use of libc. What I've found out I had to dig for. >> >> The only thing below libc is syscalls, and those are subject to change >> without notice; the same application running on different systems--or >> even the same system after an upgrade--may require different syscalls, >> and libc makes all that completely transparent. >> >> Why would you want to involve yourself in that mess? Just call libc. >> >> S >> > > I have yet to see code breakage from changed syscall ;) > If you do assembler , you don't wont 500kb of libc bloat ... > > That's about what I was thinking. Assembler or a compiler for some other language. -- Pete
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2016-02-22 00:12 -0600 |
| Message-ID | <nae8me$12d$1@dont-email.me> |
| In reply to | #160079 |
On 21-Feb-16 18:53, Melzzzzz wrote: > Stephen Sprunk <stephen@sprunk.org> wrote: >> On 20-Feb-16 19:15, Peter Flass wrote: >>> What I haven't been able to find is a "bare metal" programming >>> manual for Linux. Even the few Linux assembler books I've found >>> assume use of libc. What I've found out I had to dig for. >> >> The only thing below libc is syscalls, and those are subject to >> change without notice; the same application running on different >> systems--or even the same system after an upgrade--may require >> different syscalls, and libc makes all that completely >> transparent. >> >> Why would you want to involve yourself in that mess? Just call >> libc. > > I have yet to see code breakage from changed syscall ;) Then either you're using the INT 80 interface, which is an order of magnitude slower than SYSENTER/SYSCALL, or you've never tried porting code that uses SYSENTER/SYSCALL (which aren't always present), and you've never had to deal with EBP not being restored properly and needing to retry when a syscall is interrupted. __kernel_vsyscall() handles all of that for you, but if you're going that far, you might as well use syscall(), and then you might as well use the regular C wrappers that convert between normal and syscall calling conventions--and save you having to look up syscall numbers. > If you do assembler , you don't wont 500kb of libc bloat ... Linking to libc adds ~1500 bytes (mostly fixed overhead) to my hello world program. Considering all of the power that libc offers, that seems like a minuscule price to pay. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-02-22 09:37 +0100 |
| Message-ID | <20160222093756.4dd7f598@maxa-pc> |
| In reply to | #160085 |
On Mon, 22 Feb 2016 00:12:16 -0600 Stephen Sprunk <stephen@sprunk.org> wrote: > On 21-Feb-16 18:53, Melzzzzz wrote: > > Stephen Sprunk <stephen@sprunk.org> wrote: > >> On 20-Feb-16 19:15, Peter Flass wrote: > >>> What I haven't been able to find is a "bare metal" programming > >>> manual for Linux. Even the few Linux assembler books I've found > >>> assume use of libc. What I've found out I had to dig for. > >> > >> The only thing below libc is syscalls, and those are subject to > >> change without notice; the same application running on different > >> systems--or even the same system after an upgrade--may require > >> different syscalls, and libc makes all that completely > >> transparent. > >> > >> Why would you want to involve yourself in that mess? Just call > >> libc. > > > > I have yet to see code breakage from changed syscall ;) > > Then either you're using the INT 80 interface, which is an order of > magnitude slower than SYSENTER/SYSCALL, or you've never tried porting > code that uses SYSENTER/SYSCALL (which aren't always present), and > you've never had to deal with EBP not being restored properly and > needing to retry when a syscall is interrupted. Hm. int 0x80 does not preserve ebp rather it uses it as sixth parameter. It is not that much slower on newer cpus. In 64 bit code, syscall instruction is used rather then int 0x80. > > __kernel_vsyscall() handles all of that for you, but if you're going > that far, you might as well use syscall(), and then you might as well > use the regular C wrappers that convert between normal and syscall > calling conventions--and save you having to look up syscall numbers. > > > If you do assembler , you don't wont 500kb of libc bloat ... > > Linking to libc adds ~1500 bytes (mostly fixed overhead) to my hello > world program. Considering all of the power that libc offers, that > seems like a minuscule price to pay. If you do static linking you will see actual size. > > S >
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-02-22 09:17 -0500 |
| Message-ID | <naf553$ser$1@dont-email.me> |
| In reply to | #160089 |
Melzzzzz <mel@zzzzz.com> writes: > If you do static linking you will see actual size. What makes you think that the size reported when using dynamic linking is not an actual size? -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-02-22 15:29 +0100 |
| Message-ID | <naf607$b1u$1@news.albasani.net> |
| In reply to | #160093 |
On 2/22/16 3:17 PM, Dan Espen wrote: > Melzzzzz <mel@zzzzz.com> writes: > >> If you do static linking you will see actual size. > > What makes you think that the size reported when using dynamic > linking is not an actual size? > Check it out....
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-02-22 09:42 -0500 |
| Subject | Re: Ransomware using libc |
| Message-ID | <naf6jp$ser$2@dont-email.me> |
| In reply to | #160095 |
Melzzzzz <mel@zzzzz.com> writes: > On 2/22/16 3:17 PM, Dan Espen wrote: >> Melzzzzz <mel@zzzzz.com> writes: >> >>> If you do static linking you will see actual size. >> >> What makes you think that the size reported when using dynamic >> linking is not an actual size? >> > Check it out.... Non-answer noted. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-02-22 15:52 +0100 |
| Subject | Re: Ransomware using libc |
| Message-ID | <naf7b8$dcl$1@news.albasani.net> |
| In reply to | #160096 |
On 2/22/16 3:42 PM, Dan Espen wrote: > Melzzzzz <mel@zzzzz.com> writes: > >> On 2/22/16 3:17 PM, Dan Espen wrote: >>> Melzzzzz <mel@zzzzz.com> writes: >>> >>>> If you do static linking you will see actual size. >>> >>> What makes you think that the size reported when using dynamic >>> linking is not an actual size? >>> >> Check it out.... > > Non-answer noted. > What answer do you expect? Make program that uses input by linking with libc function eg scanf and other by using syscall. It is easy to see some 500kb added to program in memory, while with no glibc linked,program takes 4kb...
[toc] | [prev] | [next] | [standalone]
| From | Dan Espen <despen@verizon.net> |
|---|---|
| Date | 2016-02-22 10:23 -0500 |
| Subject | Re: Ransomware using libc |
| Message-ID | <naf90p$c89$1@dont-email.me> |
| In reply to | #160097 |
Melzzzzz <mel@zzzzz.com> writes: > On 2/22/16 3:42 PM, Dan Espen wrote: >> Melzzzzz <mel@zzzzz.com> writes: >> >>> On 2/22/16 3:17 PM, Dan Espen wrote: >>>> Melzzzzz <mel@zzzzz.com> writes: >>>> >>>>> If you do static linking you will see actual size. >>>> >>>> What makes you think that the size reported when using dynamic >>>> linking is not an actual size? >>>> >>> Check it out.... >> >> Non-answer noted. >> > What answer do you expect? An honest answer. > Make program that uses input by linking with libc function eg scanf > and other by using syscall. > It is easy to see some 500kb added to program in memory, while with no > glibc linked,program takes 4kb... Wasting my time. Carry on. -- Dan Espen
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2016-02-22 17:24 +0000 |
| Subject | Re: Ransomware using libc |
| Message-ID | <hvHyy.19054$Nf2.13580@fx14.iad> |
| In reply to | #160099 |
Dan Espen <despen@verizon.net> writes: >Melzzzzz <mel@zzzzz.com> writes: > >> On 2/22/16 3:42 PM, Dan Espen wrote: >>> Melzzzzz <mel@zzzzz.com> writes: >>> >>>> On 2/22/16 3:17 PM, Dan Espen wrote: >>>>> Melzzzzz <mel@zzzzz.com> writes: >>>>> >>>>>> If you do static linking you will see actual size. >>>>> >>>>> What makes you think that the size reported when using dynamic >>>>> linking is not an actual size? >>>>> >>>> Check it out.... >>> >>> Non-answer noted. >>> >> What answer do you expect? > >An honest answer. > >> Make program that uses input by linking with libc function eg scanf >> and other by using syscall. >> It is easy to see some 500kb added to program in memory, while with no >> glibc linked,program takes 4kb... > >Wasting my time. Carry on. Virtual Address Space occupied by process Resident Set Size (number of pages in memory) In the case of a statically linked executable, all the dependent functions are linked into the application, so it's text size (on disk) will be larger. The RSS will depend on the application access pattern - any text pages never referenced will never become part of the RSS (i.e. be paged into physical memory). In the case of a dynamically linked executable, all the dependent functions are provided by shared objects. When an executable is loaded, all the shared objects required are also loaded (in many cases, such as libc, they'll have been loaded already on behalf of another process and the newly exec'd process will shared the existing text pages (but get CoW data pages which will allocate as soon as the new process writes to them)). Regardless of whether the application is dynamically or statically linked, the amount of writable memory (stack, bss, data) will be identical between the two.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-02-22 20:29 +0100 |
| Subject | Re: Ransomware using libc |
| Message-ID | <20160222202905.2754fd83@maxa-pc> |
| In reply to | #160111 |
On Mon, 22 Feb 2016 17:24:29 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Dan Espen <despen@verizon.net> writes: > >Melzzzzz <mel@zzzzz.com> writes: > > > >> On 2/22/16 3:42 PM, Dan Espen wrote: > >>> Melzzzzz <mel@zzzzz.com> writes: > >>> > >>>> On 2/22/16 3:17 PM, Dan Espen wrote: > >>>>> Melzzzzz <mel@zzzzz.com> writes: > >>>>> > >>>>>> If you do static linking you will see actual size. > >>>>> > >>>>> What makes you think that the size reported when using dynamic > >>>>> linking is not an actual size? > >>>>> > >>>> Check it out.... > >>> > >>> Non-answer noted. > >>> > >> What answer do you expect? > > > >An honest answer. > > > >> Make program that uses input by linking with libc function eg scanf > >> and other by using syscall. > >> It is easy to see some 500kb added to program in memory, while > >> with no glibc linked,program takes 4kb... > > > >Wasting my time. Carry on. > > > Virtual Address Space occupied by process > Resident Set Size (number of pages in memory) > > In the case of a statically linked executable, all the dependent > functions are linked into the application, so it's text size (on > disk) will be larger. The RSS will depend on the application access > pattern - any text pages never referenced will never become part of > the RSS (i.e. be paged into physical memory). How come then simple assembler program linked with glibc has RSS of 734kb, but assembler program that is not has RSS of 4kb?
[toc] | [prev] | [next] | [standalone]
| From | Ahem A Rivet's Shot <steveo@eircom.net> |
|---|---|
| Date | 2016-02-22 19:38 +0000 |
| Subject | Re: Ransomware using libc |
| Message-ID | <20160222193846.f21c10c0e0f40feb62f48753@eircom.net> |
| In reply to | #160119 |
On Mon, 22 Feb 2016 20:29:05 +0100 Melzzzzz <mel@zzzzz.com> wrote: > On Mon, 22 Feb 2016 17:24:29 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: > > > Dan Espen <despen@verizon.net> writes: > > >Melzzzzz <mel@zzzzz.com> writes: > > > > > >> On 2/22/16 3:42 PM, Dan Espen wrote: > > >>> Melzzzzz <mel@zzzzz.com> writes: > > >>> > > >>>> On 2/22/16 3:17 PM, Dan Espen wrote: > > >>>>> Melzzzzz <mel@zzzzz.com> writes: > > >>>>> > > >>>>>> If you do static linking you will see actual size. > > >>>>> > > >>>>> What makes you think that the size reported when using dynamic > > >>>>> linking is not an actual size? > > >>>>> > > >>>> Check it out.... > > >>> > > >>> Non-answer noted. > > >>> > > >> What answer do you expect? > > > > > >An honest answer. > > > > > >> Make program that uses input by linking with libc function eg scanf > > >> and other by using syscall. > > >> It is easy to see some 500kb added to program in memory, while > > >> with no glibc linked,program takes 4kb... > > > > > >Wasting my time. Carry on. > > > > > > Virtual Address Space occupied by process > > Resident Set Size (number of pages in memory) > > > > In the case of a statically linked executable, all the dependent > > functions are linked into the application, so it's text size (on > > disk) will be larger. The RSS will depend on the application access > > pattern - any text pages never referenced will never become part of > > the RSS (i.e. be paged into physical memory). > > How come then simple assembler program linked with glibc has RSS of > 734kb, but assembler program that is not has RSS of 4kb? Because that much of libc is resident - whether it is used by your assembler program or not it is resident and so because the whole thing is mapped into the virtual memory of the process and that much is resident your process shows as having that much RSS - in truth the majority of it is shared with other processes and will never be accessed by your program. Memory accounting with shared libraries is messy because of things like this. -- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. | http://www.sohara.org/
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-02-22 21:31 +0100 |
| Subject | Re: Ransomware using libc |
| Message-ID | <20160222213119.7f28d376@maxa-pc> |
| In reply to | #160121 |
On Mon, 22 Feb 2016 19:38:46 +0000 Ahem A Rivet's Shot <steveo@eircom.net> wrote: > On Mon, 22 Feb 2016 20:29:05 +0100 > Melzzzzz <mel@zzzzz.com> wrote: > > > On Mon, 22 Feb 2016 17:24:29 GMT > > scott@slp53.sl.home (Scott Lurndal) wrote: > > > > > Dan Espen <despen@verizon.net> writes: > > > >Melzzzzz <mel@zzzzz.com> writes: > > > > > > > >> On 2/22/16 3:42 PM, Dan Espen wrote: > > > >>> Melzzzzz <mel@zzzzz.com> writes: > > > >>> > > > >>>> On 2/22/16 3:17 PM, Dan Espen wrote: > > > >>>>> Melzzzzz <mel@zzzzz.com> writes: > > > >>>>> > > > >>>>>> If you do static linking you will see actual size. > > > >>>>> > > > >>>>> What makes you think that the size reported when using > > > >>>>> dynamic linking is not an actual size? > > > >>>>> > > > >>>> Check it out.... > > > >>> > > > >>> Non-answer noted. > > > >>> > > > >> What answer do you expect? > > > > > > > >An honest answer. > > > > > > > >> Make program that uses input by linking with libc function eg > > > >> scanf and other by using syscall. > > > >> It is easy to see some 500kb added to program in memory, while > > > >> with no glibc linked,program takes 4kb... > > > > > > > >Wasting my time. Carry on. > > > > > > > > > Virtual Address Space occupied by process > > > Resident Set Size (number of pages in memory) > > > > > > In the case of a statically linked executable, all the dependent > > > functions are linked into the application, so it's text size (on > > > disk) will be larger. The RSS will depend on the application > > > access pattern - any text pages never referenced will never > > > become part of the RSS (i.e. be paged into physical memory). > > > > How come then simple assembler program linked with glibc has RSS of > > 734kb, but assembler program that is not has RSS of 4kb? > > Because that much of libc is resident - whether it is used by > your assembler program or not it is resident and so because the whole > thing is mapped into the virtual memory of the process and that much > is resident your process shows as having that much RSS - in truth the > majority of it is shared with other processes and will never be > accessed by your program. > > Memory accounting with shared libraries is messy because of > things like this. > Sorry, I never took into this seriously. Quick google search showed me that `pmap -XX pid` shows how much is shared. Seems that all of the glibc is shared as glibc RSS matches shared memory;) Bah, everyday one learns something new ;) Thanks!
[toc] | [prev] | [next] | [standalone]
| From | Charlie Gibbs <cgibbs@kltpzyxm.invalid> |
|---|---|
| Date | 2016-02-22 17:17 +0000 |
| Subject | Re: Ransomware using libc |
| Message-ID | <naffs712ttr@news3.newsguy.com> |
| In reply to | #160097 |
On 2016-02-22, Melzzzzz <mel@zzzzz.com> wrote: > On 2/22/16 3:42 PM, Dan Espen wrote: > >> Melzzzzz <mel@zzzzz.com> writes: >> >>> On 2/22/16 3:17 PM, Dan Espen wrote: >>> >>>> Melzzzzz <mel@zzzzz.com> writes: >>>> >>>>> If you do static linking you will see actual size. >>>> >>>> What makes you think that the size reported when using dynamic >>>> linking is not an actual size? >>>> >>> Check it out.... >> >> Non-answer noted. > > What answer do you expect? > Make program that uses input by linking with libc function eg scanf > and other by using syscall. > It is easy to see some 500kb added to program in memory, while with no > glibc linked,program takes 4kb... Chances are, some other program is already running that uses libc. If such is the case, it's already in memory. Why not use it? -- /~\ cgibbs@kltpzyxm.invalid (Charlie Gibbs) \ / I'm really at ac.dekanfrus if you read it the right way. X Top-posted messages will probably be ignored. See RFC1855. / \ HTML will DEFINITELY be ignored. Join the ASCII ribbon campaign!
[toc] | [prev] | [next] | [standalone]
| From | Stephen Sprunk <stephen@sprunk.org> |
|---|---|
| Date | 2016-02-22 14:41 -0600 |
| Subject | Re: Ransomware using libc |
| Message-ID | <nafrkt$qbc$1@dont-email.me> |
| In reply to | #160097 |
On 22-Feb-16 08:52, Melzzzzz wrote: > On 2/22/16 3:42 PM, Dan Espen wrote: >> Melzzzzz <mel@zzzzz.com> writes: >>> On 2/22/16 3:17 PM, Dan Espen wrote: >>>> Melzzzzz <mel@zzzzz.com> writes: >>>>> If you do static linking you will see actual size. My system doesn't even _have_ a libc.a because static linking to libc is not a remotely reasonable thing to do. >>>> What makes you think that the size reported when using dynamic >>>> linking is not an actual size? >>>> >>> Check it out.... >> >> Non-answer noted. >> > What answer do you expect? Make program that uses input by linking > with libc function eg scanf and other by using syscall. There is no syscall for scanf(), so that's apples and oranges. My hello world asm examples are 344 bytes for an executable that uses the write() and exit() syscalls directly and 1875 bytes for one that uses the libc wrappers. That's trivial once you realize that's mostly fixed overhead, not per call or even per wrapper. > It is easy to see some 500kb added to program in memory, while with > no glibc linked,program takes 4kb... Of course libc.so gets mapped into the latter example's address space, along with a couple other things, but so what? They're already in RAM (and probably L2 cache, if not L1) due to use by other processes, so the real-world cost of that is zero. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-02-22 22:07 +0100 |
| Subject | Re: Ransomware using libc |
| Message-ID | <20160222220723.66ecdf93@maxa-pc> |
| In reply to | #160126 |
On Mon, 22 Feb 2016 14:41:51 -0600 Stephen Sprunk <stephen@sprunk.org> wrote: > On 22-Feb-16 08:52, Melzzzzz wrote: > > On 2/22/16 3:42 PM, Dan Espen wrote: > >> Melzzzzz <mel@zzzzz.com> writes: > >>> On 2/22/16 3:17 PM, Dan Espen wrote: > >>>> Melzzzzz <mel@zzzzz.com> writes: > >>>>> If you do static linking you will see actual size. > > My system doesn't even _have_ a libc.a because static linking to libc > is not a remotely reasonable thing to do. > > >>>> What makes you think that the size reported when using dynamic > >>>> linking is not an actual size? > >>>> > >>> Check it out.... > >> > >> Non-answer noted. > >> > > What answer do you expect? Make program that uses input by linking > > with libc function eg scanf and other by using syscall. > > There is no syscall for scanf(), so that's apples and oranges. > > My hello world asm examples are 344 bytes for an executable that uses > the write() and exit() syscalls directly and 1875 bytes for one that > uses the libc wrappers. That's trivial once you realize that's mostly > fixed overhead, not per call or even per wrapper. my hello that uses read/write exit syscalls is 266 bytes (64 bit). somewhat complicated glibc example that uses scanf/fopen/fwrite/fclose exit is 1293 bytes also 64 bit. > > > It is easy to see some 500kb added to program in memory, while with > > no glibc linked,program takes 4kb... > > Of course libc.so gets mapped into the latter example's address space, > along with a couple other things, but so what? They're already in RAM > (and probably L2 cache, if not L1) due to use by other processes, so > the real-world cost of that is zero. > > S > Nevermind, I didn't pay attention to shared memory. Those 500kb or so are actually shared with other processes ;)
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-02-22 09:16 -0700 |
| Message-ID | <1b37skyb3m.fsf@pfeifferfamily.net> |
| In reply to | #160089 |
Melzzzzz <mel@zzzzz.com> writes: > On Mon, 22 Feb 2016 00:12:16 -0600 > Stephen Sprunk <stephen@sprunk.org> wrote: >> >> Linking to libc adds ~1500 bytes (mostly fixed overhead) to my hello >> world program. Considering all of the power that libc offers, that >> seems like a minuscule price to pay. > > If you do static linking you will see actual size. That's only relevant if your new program is the only one on the system using libc.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <mel@zzzzz.com> |
|---|---|
| Date | 2016-02-22 17:21 +0100 |
| Message-ID | <nafcj7$o7o$1@news.albasani.net> |
| In reply to | #160101 |
On 2/22/16 5:16 PM, Joe Pfeiffer wrote: > Melzzzzz <mel@zzzzz.com> writes: > >> On Mon, 22 Feb 2016 00:12:16 -0600 >> Stephen Sprunk <stephen@sprunk.org> wrote: >>> >>> Linking to libc adds ~1500 bytes (mostly fixed overhead) to my hello >>> world program. Considering all of the power that libc offers, that >>> seems like a minuscule price to pay. >> >> If you do static linking you will see actual size. > > That's only relevant if your new program is the only one on the system > using libc. > I don't think so... linking with glibc adds resident usage of 500kb to program memory.
[toc] | [prev] | [next] | [standalone]
Page 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
Back to top | Article view | alt.folklore.computers
csiph-web