Black Hat Rust Applied offensive security with

the Rust programming language Sylvain Kerkour

install download

https://ebookmeta.com/product/black-hat-rust-applied-offensive-
security-with-the-rust-programming-language-sylvain-kerkour/

Download more ebook from https://ebookmeta.com

We believe these products will be a great fit for you. Click
the link to download now, or visit ebookmeta.com
to discover even more!

Black Hat Rust Applied offensive security with the Rust

programming language Sylvain Kerkour

https://ebookmeta.com/product/black-hat-rust-applied-offensive-
security-with-the-rust-programming-language-sylvain-kerkour-3/

Black Hat Rust Applied offensive security with the Rust

programming language Sylvain Kerkour

https://ebookmeta.com/product/black-hat-rust-applied-offensive-
security-with-the-rust-programming-language-sylvain-kerkour/

Black Hat Rust Deep dive into offensive security with

the Rust programming language Sylvain Kerkour

https://ebookmeta.com/product/black-hat-rust-deep-dive-into-
offensive-security-with-the-rust-programming-language-sylvain-
kerkour/

Agriscience: Fundamentals and Applications, Sixth

Edition L Devere Burton

https://ebookmeta.com/product/agriscience-fundamentals-and-
applications-sixth-edition-l-devere-burton/
Letting Data Lead How to Design Analyze and Respond to
Classroom Assessment Gain Actionable Insights Through
Effective Assessment Methods and Data Interpretation
1st Edition Eileen Depka
https://ebookmeta.com/product/letting-data-lead-how-to-design-
analyze-and-respond-to-classroom-assessment-gain-actionable-
insights-through-effective-assessment-methods-and-data-
interpretation-1st-edition-eileen-depka/

The Bear the Bat and the Dove Three Stories from Aesop
Rob Cleveland

https://ebookmeta.com/product/the-bear-the-bat-and-the-dove-
three-stories-from-aesop-rob-cleveland/

Software Defined Radio: Theory and Practice (Artech

House Mobile Communications Library) 1st Edition
Reyland

https://ebookmeta.com/product/software-defined-radio-theory-and-
practice-artech-house-mobile-communications-library-1st-edition-
reyland/

No Truth Without Beauty God the Qur an and Women s

Rights Sustainable Development Goals Series El-Ali

https://ebookmeta.com/product/no-truth-without-beauty-god-the-
qur-an-and-women-s-rights-sustainable-development-goals-series-
el-ali/

Perfect Phrases™ for ESL: Conversation Skills Diane

Engelhardt

https://ebookmeta.com/product/perfect-phrases-for-esl-
conversation-skills-diane-engelhardt/
Redemption Dr Rebecca Sharp

https://ebookmeta.com/product/redemption-dr-rebecca-sharp/
Black Hat Rust
Applied offensive security with the Rust
programming language

Sylvain Kerkour
 Black Hat Rust
Applied offensive security with the Rust programming language

Sylvain Kerkour

v2021.46
Contents

Copyright 7

Your early access bonuses 8

Contact 9

Preface 10

1 Introduction 13
1.1 Types of attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.2 Phases of an attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Profiles of attackers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Attribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.5 The Rust programming language . . . . . . . . . . . . . . . . . . . . . 19
1.6 History of Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.7 Rust is awesome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.8 Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.9 Our first Rust program: A SHA-1 hash cracker . . . . . . . . . . . . . 25
1.10 Mental models for approaching Rust . . . . . . . . . . . . . . . . . . . 31
1.11 A few things I’ve learned along the way . . . . . . . . . . . . . . . . . . 33
1.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

2 Multi-threaded attack surface discovery 42

2.1 Passive reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2 Active reconnaissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.3 Assets discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4 Our first scanner in Rust . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.5 Error handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.6 Enumerating subdomains . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.7 Scanning ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.8 Multithreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.9 Fearless concurrency in Rust . . . . . . . . . . . . . . . . . . . . . . . . 49
2.10 The three causes of data races . . . . . . . . . . . . . . . . . . . . . . . 52
2.11 The three rules of ownership . . . . . . . . . . . . . . . . . . . . . . . . 52
2.12 The two rules of references . . . . . . . . . . . . . . . . . . . . . . . . . 52
2.13 Other concurrency problems . . . . . . . . . . . . . . . . . . . . . . . . 53
2.14 Adding multithreading to our scanner . . . . . . . . . . . . . . . . . . . 53

1
 2.15 Alternatives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.16 Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.17 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3 Going full speed with async 58

3.1 Why . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.2 Cooperative vs Preemptive scheduling . . . . . . . . . . . . . . . . . . 59
3.3 Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4 Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5 What is a runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6 Introducing tokio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.7 Avoid blocking the event loops . . . . . . . . . . . . . . . . . . . . . . . 64
3.8 Sharing data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.9 Combinators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.10 Porting our scanner to async . . . . . . . . . . . . . . . . . . . . . . . . 82
3.11 How to defend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4 Adding modules with trait objects 88

4.1 Generics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.2 Traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.3 Traits objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.4 Command line argument parsing . . . . . . . . . . . . . . . . . . . . . 100
4.5 Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.6 Adding modules to our scanner . . . . . . . . . . . . . . . . . . . . . . 102
4.7 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.8 Other scanners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.9 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

5 Crawling the web for OSINT 114

5.1 OSINT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.2 Tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.3 Search engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.4 IoT & network Search engines . . . . . . . . . . . . . . . . . . . . . . . 117
5.5 Social media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.6 Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.7 Videos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.8 Government records . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.9 Crawling the web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.10 Why Rust for crawling . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.11 Associated types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.12 Atomic types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
5.13 Barrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.14 Implementing a crawler in Rust . . . . . . . . . . . . . . . . . . . . . . 124
5.15 The spider trait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.16 Implementing the crawler . . . . . . . . . . . . . . . . . . . . . . . . . 125
5.17 Crawling a simple HTML website . . . . . . . . . . . . . . . . . . . . . 129

2
 5.18 Crawling a JSON API . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
5.19 Crawling a JavaScript web application . . . . . . . . . . . . . . . . . . 133
5.20 How to defend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.21 Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.22 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138

6 Finding vulnerabilities 139

6.1 What is a vulnerability . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
6.2 Weakness vs Vulnerability (CWE vs CVE) . . . . . . . . . . . . . . . . 139
6.3 Vulnerability vs Exploit . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.4 0 Day vs CVE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.5 Web vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.6 Injections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.7 HTML injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
6.8 SQL injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
6.9 XSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.10 Server Side Request Forgery (SSRF) . . . . . . . . . . . . . . . . . . . 147
6.11 Cross-Site Request Forgery (CSRF) . . . . . . . . . . . . . . . . . . . . 149
6.12 Open redirect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6.13 (Sub)Domain takeover . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
6.14 Arbitrary file read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
6.15 Denial of Service (DoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
6.16 Arbitrary file write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
6.17 Memory vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.18 Buffer overflow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
6.19 Use after free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
6.20 Double free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
6.21 Other vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6.22 Remote Code Execution (RCE) . . . . . . . . . . . . . . . . . . . . . . 160
6.23 Integer overflow (and underflow) . . . . . . . . . . . . . . . . . . . . . . 161
6.24 Logic error . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.25 Race condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
6.26 Additional resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.27 Bug hunting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
6.28 The tools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
6.29 Automated audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
6.30 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172

7 Exploit development 173

7.1 Where to find exploits . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
7.2 Creating a crate that is both a library and a binary . . . . . . . . . . . 174
7.3 libc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
7.4 Building an exploitation toolkit . . . . . . . . . . . . . . . . . . . . . . 176
7.5 CVE-2019-11229 && CVE-2019-89242 . . . . . . . . . . . . . . . . . . 176
7.6 CVE-2021-3156 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
7.7 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181

3
8 Writing shellcodes in Rust 182
8.1 What is a shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
8.2 Sections of an executable . . . . . . . . . . . . . . . . . . . . . . . . . . 183
8.3 Rust compilation process . . . . . . . . . . . . . . . . . . . . . . . . . . 184
8.4 no_std . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
8.5 Using assembly from Rust . . . . . . . . . . . . . . . . . . . . . . . . . 187
8.6 The never type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8.7 Executing shellcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
8.8 Our linker script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
8.9 Hello world shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
8.10 An actual shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
8.11 Reverse TCP shellcode . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
8.12 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203

9 Phishing with WebAssembly 204

9.1 Social engineering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
9.2 Nontechnical hacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
9.3 Phishing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
9.4 Watering holes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
9.5 Telephone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
9.6 WebAssembly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
9.7 Sending emails in Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
9.8 Implementing a phishing page in Rust . . . . . . . . . . . . . . . . . . 218
9.9 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
9.10 Cargo Workspaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
9.11 Deserialization in Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
9.12 A client application with WebAssembly . . . . . . . . . . . . . . . . . . 220
9.13 Evil twin attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
9.14 How to defend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
9.15 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

10 A modern RAT 235

10.1 Architecture of a RAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
10.2 C&C channels & methods . . . . . . . . . . . . . . . . . . . . . . . . . 237
10.3 Existing RAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
10.4 Why Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
10.5 Designing the server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
10.6 Designing the agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
10.7 Docker for offensive security . . . . . . . . . . . . . . . . . . . . . . . . 252
10.8 Let’s code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
10.9 Optimizing Rust’s binary size . . . . . . . . . . . . . . . . . . . . . . . 273
10.10Some limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
10.11Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274

11 Securing communications with end-to-end encryption 275

11.1 The C.I.A triad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
11.2 Threat modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277

4
 11.3 Cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
11.4 Hash functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
11.5 Message Authentication Codes . . . . . . . . . . . . . . . . . . . . . . . 278
11.6 Key derivation functions . . . . . . . . . . . . . . . . . . . . . . . . . . 280
11.7 Block ciphers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
11.8 Authenticated encryption (AEAD) . . . . . . . . . . . . . . . . . . . . 281
11.9 Asymmetric encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
11.10Diffie–Hellman key exchange . . . . . . . . . . . . . . . . . . . . . . . . 284
11.11Signatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
11.12End-to-end encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
11.13Who uses cryptography . . . . . . . . . . . . . . . . . . . . . . . . . . 294
11.14Common problems and pitfalls with cryptography . . . . . . . . . . . . 295
11.15A little bit of TOFU? . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
11.16The Rust cryptography ecosystem . . . . . . . . . . . . . . . . . . . . . 296
11.17Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
11.18Our threat model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
11.19Designing our protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
11.20Implementing end-to-end encryption in Rust . . . . . . . . . . . . . . . 303
11.21Some limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
11.22To learn more . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
11.23Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315

12 Going multi-platforms 316

12.1 Why multi-platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
12.2 Cross-platform Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
12.3 Supported platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318
12.4 Cross-compilation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
12.5 cross . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
12.6 Custom Dockerfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321
12.7 Cross-compiling to aarch64 (arm64) . . . . . . . . . . . . . . . . . . . . 322
12.8 More Rust binary optimization tips . . . . . . . . . . . . . . . . . . . . 323
12.9 Packers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
12.10Persistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
12.11Single instance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
12.12Going further . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
12.13Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330

13 Turning our RAT into a worm to increase reach 331

13.1 What is a worm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
13.2 Spreading techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332
13.3 Cross-platform worm . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334
13.4 Spreading through SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
13.5 Vendoring dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . 336
13.6 Implementing a cross-platform worm in Rust . . . . . . . . . . . . . . . 337
13.7 Install . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
13.8 Spreading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
13.9 More advanced techniques for your RAT . . . . . . . . . . . . . . . . . 343

5
 13.10Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347

14 Conclusion 348
14.1 What we didn’t cover . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
14.2 The future of Rust . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
14.3 Leaked repositories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
14.4 How bad guys get caught . . . . . . . . . . . . . . . . . . . . . . . . . 350
14.5 Your turn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
14.6 Build your own RAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
14.7 Other interesting blogs . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
14.8 Contact . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355

6
Copyright

Copyright © 2021 Sylvain Kerkour

All rights reserved. No portion of this book may be reproduced in any form without
permission from the publisher, except as permitted by law. For permissions contact:
[email protected]

7
Your early access bonuses

Dear reader, in order to thank you for buying the Black Hat Rust early access edition
and helping to make this book a reality, I prepared you a special bonus: I curated a
list of the best detailed analyses of the most advanced malware of the past two decades.
You may find inside great inspiration when developing your own offensive tools. You
can find the list at this address: https://github.com/black-hat-rust-bonuses/black-
hat-rust-bonuses

If you notice a mistake (it happens), something that could be improved, or want to
share your ideas about offensive security, feel free to join the discussion on Github:
https://github.com/skerkour/black-hat-rust

8
Contact

I regularly publish content that is complementary to this book in my newsletter.

Every week I share updates about my projects and everything I learn about how to
(ab)use technology for fun & profit: Programming, Hacking & Entrepreneurship. You
can subscribe by Email or RSS: https://kerkour.com/follow.

You bought the book and are annoyed by something? Please tell me, and I will do my
best to improve it!

Or, you greatly enjoyed the read and want to say thank you?

Feel free to contact me by email: [email protected] or matrix: @sylvain:kerkour.com

You can find all the updates in the changelog.

9
Preface

After high school, my plan for life was to become a private detective, maybe because
I read too many Sherlock Holmes books. In France, the easiest way to become one is
(was?) to go to law university and then to attend a specialized school.

I was not ready.

I quickly realized that studying law was not for me: reality is travestied to fit whatever
narrative politics or professor wanted us to believe. No deep knowledge is taught here,
only numbers, dates, how to look nice and sound smart. It was deeply frustrating for
the young man I was, with an insatiable curiosity. I wanted to understand how the
world works, not human conventions. For example, how do these machines we call
computers that we are frantically typing on all day long work under the hood?

So I started by installing Linux (no, I won’t enter the GNU/Linux war) on my Asus
EeePC, a small netbook with only 1GB of RAM, because Windows was too slow, and
started to learn to develop C++ programs with Qt, thanks to online tutorials. I coded
my own text and my own chat systems. But my curiosity was not fulfilled.

One day, I inadvertently fell on the book that changed my life: “Hacking: The Art of
Exploitation, 2nd Edition”, by Jon Erickson.

This book not only made me curious about how to make things, but, more importantly,
how to break things. It made me realize that you can’t build reliable things without
understanding how to break them, and by extension, where their weaknesses are.

While the book remains great to learn low-level programming and how to exploit simple
memory safety bugs, today, hacking requires new skills: web exploitation, network and
system programming, and, above all, how to code in a modern programming language.

Welcome to the fascinating world of Rust and offensive security.

While the Rust Book does an excellent job teaching What is Rust, I felt that a book
about Why and How to Rust was missing. That means that some concepts will not

10
be covered in-depth in this book. Instead, we are going to see how to effectively use
them in practice.

In this book, we will shake the preconceived ideas (Rust is too complex for the real world,
Rust is not productive…) and see how to architect and create real-world Rust projects
applied to offensive security. We will see how polyvalent Rust is, which enables its users
to replace the plethora of programming languages (Python, Ruby, C, C++…) plaguing
the offensive security world with a unique language that offers high-level abstractions,
high performance, and low-level control when needed.

We will always start with some theory, deep knowledge that pass through ages, tech-
nologies and trends. This knowledge is independent of any programming language and
will help you to get the right mindset required for offensive security.

I designed this book for people who either want to understand how attackers think in
order to better defend themselves or for people who want to enter the world of offensive
security and eventually make a living off it.

The goal of this book is to save you time in your path to action, by distilling knowledge
and presenting it in applied code projects.

It’s important to understand that Black Hat Rust is not meant to be a big encyclopedia
containing all the knowledge of the world. Instead, it was designed as a guide to help
you getting started and pave the way to action. Knowledge is often a prerequisite,
but it’s action that is shaping the world, and sometimes knowledge is a blocker for
action (see analysis paralysis). As we will see, some of the most primitive offensive
techniques are still the most effective. Thus some very specific topics, such as how to
bypass modern OSes protection mechanisms won’t be covered because there already is
extensive literature on these topics, and they have little value in a book about Rust.
That being said, I did my best to list the best resources to further your learning journey.

It took me approximately 1 year to become efficient in Rust, but it’s only when I started
to write (and rewrite) a lot of code that I made real progress.

Rust is an extremely vast language, but in reality, you will (and should) use only a
subset of its features: you don’t need to learn them all ahead of time. Some, that we
will study in this book, are fundamentals. Others are not and may have an adversarial
effect on the quality of your code by making it harder to read and maintain.

My intention with this book is not only to make you discover the fabulous world of
offensive security, to convince you that Rust is the long-awaited one-size-fits-all pro-
gramming language meeting all the needs of offensive security, but also to save you

11
a lot of time by guiding you to what really matters when learning Rust and offensive
security. But remember, knowledge is not enough. Knowledge doesn’t move mountains.
Actions do.

Thus, the book is only one half of the story. The other half is the accompanying code
repository: https://github.com/skerkour/black-hat-rust. It’s impossible to learn
without practice, so I invite you to read the code, modify it and make it
yours!

If at any time you feel lost or don’t understand a chunk of Rust code, don’t hesitate
to refer to the Rust Language Cheat Sheet, The Rust Book, and the Rust Language
Reference.

Also, the book is code-heavy. I recommend reading it with a web browser aside, in order
to explore and play with the code on GitHub: https://github.com/skerkour/black-hat-
rust/.

12
Chapter 1

Introduction

“Any sufficiently advanced cyberattack is indistinguishable from magic”, unknown

Whether it be in movies or in mainstream media, hackers are often romanticized: they

are depicted as black magic wizards, nasty criminals, or, in the worst cases, as thieves
with a hood and a crowbar.

In reality, the spectrum of the profile of the attackers is extremely large, from the bored
teenager exploring the internet to sovereign State’s armies as well as the unhappy former
employee. As we will see, cyberattacks are not that hard. Knowledge is simply unevenly
distributed and jealously kept secret by the existing actors. The principal ingredients
are a good dose of curiosity and the courage to follow your instinct.

As digital is taking an always more important place in our lives, the impact and scale
of cyberattacks will increase in the same way: we are helplessly witnessing during
the current COVID-19 pandemic attacks against our hospitals which have real-life and
dramatic consequences.

It’s time to fight back and to prepare ourselves for the wars and battles of today (not
tomorrow) and to understand that, in order to defend, there is no other way than
to put ourselves in the shoes of attackers and think how they think. What are their
motivations? How can they break seemingly so easily into any system? What do they
do to their victims? From theory to practice, we will explore the arcanes of offensive
security and build our own offensive tools with the Rust programming language.

Why Rust?

The world of security (and, more generally, software) is plagued by too many program-
ming languages with too many footguns. You have to choose between fast and unsafe
(C, C++…) or slow but mostly safe (Python, Java…).

13
Can someone be an expert in all these languages? I don’t think so. And the countless
bugs and vulnerabilities in offensive tools prove I’m right.

What if, instead, we could have a unique language.

A language that, once mastered, would fill all the needs of the field:

• Shellcodes
• Cross-platform Remote Access Tools (RATs)
• Reusable and embeddable exploits
• Scanners
• Phishing toolkits
• Embedded programming
• Web servers
• …

What if we had a single language that is low-level enough while providing high-level
abstractions, is exceptionally fast, and easy to cross-compile. All of that while being
memory safe, highly reusable, and extremely reliable.

No more weird toolchains, strange binary packagers, vulnerable network code, injectable
phishing forms…

You got it, Rust is the language to rule them all.

Due to momentum, Rust isn’t widely adopted by the security industry yet, but once the
tech leads and independent hackers understand this reality, I believe that the change
will happen really fast.

Of course, there are some pitfalls and a few things to know, but everything is covered
in the following chapters.

1.1 Types of attacks

All attacks are not necessarily illegal or unsolicited. Let’s start with a quick summary
of the most common kinds of attacks found in the wild.

1.1.1 Attacks without a clear goal

Teenagers have an obscene amount of free time. Thus, some of them may start learning
computer security after school and hack random targets on the internet. Even if they
may not have clear goals in mind other than inflating their ego and appeasing their
curiosity, these kinds of attacks can still have substantial monetary costs for the victims.

14
1.1.2 Political attacks
Sometimes, attacks have the only goal of spreading a political message. Most of the
time, they materialize as website defacements where websites’ content is replaced with
the political message, or denial-of-service attacks where a piece of infrastructure or a
service is made unavailable.

1.1.3 Pentest
Pentest, which stands for Penetration Testing, may be the most common term used to
designate security audits. One downside of pentests is that sometimes they are just a
means to check boxes for compliance purposes, are performed using simple automated
scanners, and may leave big holes open.

1.1.4 Red team

Red teaming is seen as an evolution of traditional pentests: attackers are given more
permissions and a broader scope like phishing employees, using implants or even physical
penetration. The idea is: in order to protect against attacks, auditors have to think
and operate like real attackers.

1.1.5 Bug bounty

Bug bounty programs are the uberization of security audits. Basically, companies say:
“Try to hack me. If you find something and report it to me, I will pay you”.

As we will see in the last chapter, bug bounty programs have their limits and are
sometimes used by companies as virtue signaling instead of real security measures.

1.1.6 Cybercrime
Cybercrime is definitely the most growing type of attack since the 2010s. From selling
personal data on underground forums to botnets and ransomwares or credit card hack-
ing, criminal networks have found many creative ways of acting. An important peak
occurred in 2017, when the NSA tools and exploits were leaked by the mysterious group
“Shadow Brokers”, which were then used in other malware such as WanaCry and Petya.

Despite the strengthening of online services to reduce the impact of data-stealing (today,
it is far more difficult to take advantage of a stolen card number compared to a few years
ago), criminals always find new creative ways to monetize their wrongdoings, especially
with cryptocurrencies.

15
1.1.7 Industrial spying
Industrial espionage has always been a tempting means for companies to break down
competitors’ secrets and achieve competitive advantage. As our economy is more and
more dematerialized (digitalized), this kind of attack will only increase in terms of
frequency.

1.1.8 Cyberwar
This last kind of attack is certainly the less mediatized but without doubt the most
spectacular. To learn more about this exciting topic, I can’t recommend enough the
excellent book “Countdown to Zero Day: Stuxnet and the Launch of the World’s First
Digital Weapon” by Kim Zetter which tells the story of, to my knowledge, the first act
of advanced cyberwar: the Stuxnet worm.

1.2 Phases of an attack

Figure 1.1: Phases of an attack

1.2.1 Reconnaissance
The first phase consists of gathering as much information as possible about the target.
Whether it be the names of the employees, the numbers of internet-facing machines
and the services running on them, the list of the public Git repositories…

Reconnaissance is either passive (using publicly available data sources, such as social
networks or search engines), or active (scanning the target’s networks directly, for ex-
ample).

1.2.2 Exploitation
Exploitation is the initial breach. It can be performed by using exploits (zero-day
or not), abusing humans (social engineering) or both (sending office documents with
malware inside).

16
1.2.3 Lateral Movements
Also known as pivoting, lateral movement designates the process of maintaining access
and gaining access to more resources and systems. Implants, Remote Access Tools
(RATs), and various other tools are used during this phase. The biggest challenge is to
stay hidden as long as possible.

1.2.4 Data exfiltration

Data exfiltration is not present in every cyberattack, but in most which are not carried
out by criminals: industrial spying, banking trojans, State spying…

It should be made with care as large chunks of data passing through the network may
not go unnoticed.

1.2.5 Clean up
Once the attack is successfully completed, advised attackers need to cover their tracks
in order to reduce the risk of being identified: logs, temporary files, infrastructure,
phishing websites…

1.3 Profiles of attackers

The profile of attackers is also extremely varied. From lone wolves to teams of hackers,
developers and analysts, there is definitely not a common profile that fits them all.
However, in this section, I will try to portray which profiles should be part of a team
conducting offensive operations.

1.3.1 The hacker

The term hacker is controversial: mainstream media use it to describe criminals while
tech people use it to describe passionate or hobbyists tinkering with tech. In our context,
we will use it to describe the person with advanced offensive skills and whose role is to
perform reconnaissance and exploitation of the targets.

1.3.2 The exploit writer

The exploit writers are often developers with a deep understanding of security. Their
role is to craft the weapons used by their teams to break into their targets’ networks
and machines.

17
Exploit development is also known as “weaponization”.

Entire companies are operating in the grey waters of exploits trading, such as Vupen or
Zerodium. They often don’t find the exploits themselves but buy them from third-party
hackers and find buyers (such as government agencies or malware developers).

1.3.3 The developer

The role of the developer is to build custom tools (credential dumpers, proxies…) and
implants used during the attack. Indeed, using publicly available, pre-made tools vastly
increase the risk of being detected.

These are the skills we will learn and practice in the next chapters.

1.3.4 The system administrator

Once the initial compromise is performed, the role of the system administrator is to
operate and secure the infrastructure used by attackers. Their knowledge can also be
used during the exploitation and lateral movements phases.

1.3.5 The analyst

In all kinds of attacks, domain knowledge is required to interpret the findings and
prioritize targets. This is the role of the analyst, either to provide deep knowledge
about what specifically to target or to make sense of the exfiltrated data.

1.4 Attribution
Attribution is the process of identifying and laying blame on the operators behind a
cyber attack.

As we will see, it’s an extremely complex topic: sophisticated attackers go through

multiple networks and countries before hitting their target.

Attacks attribution is usually based on the following technical and operational elements:

Dates and time of the attackers’ activities, which may reveal their time zone - even
though it can easily be manipulated by moving the team to another country.

Artifacts present in the employed malware, like a string of characters in a specific

alphabet or language - although, one can insert another language in order to blame
someone else.

18
By counterattacking or hacking attackers’ tools and infrastructure, or even by sending
them false data which may lead them to make mistakes and consequently reveal their
identities.

Finally, by browsing forums: it’s not unusual that hackers praise their achievements on
dedicated forums in order to both inflate their reputation and ego.

In the context of cyberwar, it is important to remember that public naming of attackers

might sometimes be related to a political agenda rather than concrete facts.

1.5 The Rust programming language

Now we have a better idea of what cyberattacks are and who is behind them, let see
how they can be carried out. Usually, offensive tools are developed in the C, C++,
Python, or Java programming languages, and now a bit of Go. But all these languages
have flaws that make them far from optimal for the task: it’s extremely hard to write
safe and sound programs in C or C++, Python can be slow, and due to its weak typing,
it’s hard to write large programs and Java depends on a heavyweight runtime which
may not fit all requirements when developing offensive tools.

If you are hanging out online on forums like HackerNews or Reddit, you can’t have
missed this “new” programming language called Rust. It pops almost every time we
are discussing something barely related to programming. The so-called Rust Evangelism
Strikeforce is promising access to paradise to the brave programmers who will join their
ranks.

Rust is turning a new page in the history of programming languages by providing

unparalleled guarantees and features, whether it be for defensive or offensive security. I
will venture to say that Rust is the long-awaited one-size-fits-all programming language.
Here is why.

1.6 History of Rust

According to Wikipedia, “Rust was originally designed by Graydon Hoare at Mozilla
Research, with contributions from Dave Herman, Brendan Eich, and others. The de-
signers refined the language while writing the Servo layout or browser engine, and the
Rust compiler”.

Since then, the language has been following an organic growth and is today, according
to Stack Overflow’s surveys, the most loved language by software developers for 5 years

19
in a row.

Figure 1.2: Google trends results for the Rust programming language

Lately, big organizations such as Amazon or Microsoft have publicly announced their
love for the language and are creating internal talent pools.

With that being said, Rust is still a niche language today and is not widely used outside
of these big companies.

1.7 Rust is awesome

1.7.1 The compiler
First hated by beginners then loved, the Rust compiler is renowned for its strictness.
You should not take its rejections personally. Instead, see it like an always available
code reviewer, just not that friendly.

1.7.2 Fast
One of the most loved characteristics of Rust is its speed. Developers spend their day be-
hind a screen and hate slow programs interrupting their workflows. It is thus completely
natural that programmers tend to reject slow programming language contaminating the
whole computing stack and creating painful user experiences.

Micro-benchmarks are of no interest to us because they are more often than not falla-
cious. However, there are a lot of reports demonstrating that Rust is blazing fast when

20
 Figure 1.3: Google trends: Rust VS Go

used in real-world applications.

My favorite one is Discord describing how replacing a service in Go by one in Rust not
only eliminated latency spikes due to Go’s garbage collector but also reduced average
response time from milliseconds to microseconds.

Another one is TechEmpower’s Web Framework benchmarks, certainly the most exhaus-
tive web framework benchmarks available on the internet where Rust shines since 2018.
Some may argue that this one is a micro-benchmark, as the code is over-optimized
for some specific, pre-determined use cases, yet, the result correlates with what I can
observe in the real world.

1.7.3 Multi-paradigm
Being greatly inspired by the ML family of programming languages, Rust can be de-
scribed as easy to learn as imperative programming languages, and as expressive as
functional programming languages, whose abstractions allow them to transpose the
human thoughts to code better.

Rust is rather “low-level” but offers high-level abstractions to programmers and thus is
a joy to use.

The most loved feature by programmers coming from other programming languages
seems to be enums, also known as Algebraic Data Types. They offer unparalleled ex-
pressiveness and correctness: when we “check” an enum, with the match keyword, the

21
compiler makes sure that we don’t forget a case, unlike switch statements in other program-
ming languages.

ch_01/snippets/enums/src/lib.rs

pub enum Status {

Queued,
Running,
Failed,
}

pub fn print_status(status: Status) {

match status {
Status::Queued => println!("queued"),
Status::Running => println!("running"),
}
}

$ cargo build
Compiling enums v0.1.0
error[E0004]: non-exhaustive patterns: `Failed` not covered
--> src/lib.rs:8:11
|
1 | / pub enum Status {
2 | | Queued,
3 | | Running,
4 | | Failed,
| | ------ not covered
5 | | }
| |_- `Status` defined here
...
8 | match status {
| ^^^^^^ pattern `Failed` not covered
|
= help: ensure that all possible cases are being handled, possibly by adding
↪ wildcards or more match arms
= note: the matched value is of type `Status`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0004`.
error: could not compile `enums`

To learn more, run the command again with --verbose.

22
1.7.4 Modular
Rust’s creators clearly listened to developers when designing the ecosystem of tools accompany-
ing it. It especially shows regarding dependencies management. Rust’s package management
(known as “crates”) is as easy as with dynamic languages, such as Node.js’ NPM, a real breath
of fresh air when you had to fight with C or C++ toolchains, static and dynamic libraries.

1.7.5 Explicit
Rust’s is certainly one of the most explicit languages. On the one hand, it allows programs
to be easier to reason about and code reviews to be more effective as fewer things are hidden.

On the other hand, it is often pointed out by people on forums, telling that they never saw
such an ugly language because of its verbosity.

1.7.6 The community

This section couldn’t be complete if I didn’t talk about the community. From kind help on
forums to free educational material, Rust’s community is known to be among the most (if not
the most) welcoming, helpful, and friendly online communities.

I would speculate that this is due to the fact that today, not so many companies are using
Rust. Thus, the community is mostly composed of passionate programmers for whom sharing
about the language is more a passion than a chore.

You can learn more about the companies using Rust in production in my blog post: 42
Companies using Rust in production (in 2021).

Where do Rustaceans hang out online?

• The Rust’s users forum

• The Rust’s Subreddit
• On Matrix: #rust:matrix.org
• On Discord

I personally use Reddit to share my projects or ideas with the community, and the forum to
seek help about code.

1.8 Setup
Before starting to code, we need to set up our development environment. We will need
(without surprise) Rust, a code editor, and Docker.

23
1.8.1 Install Rust(up)
rustup is the official way to manage Rust toolchains on your computer. It will be needed
to update Rust and install other components like the automatic code formatter: rustfmt.

It can be found online at https://rustup.rs

1.8.2 Installing a code editor

The easiest to use and most recommended free code editor available today is Visual Studio
Code by Microsoft.

You can install it by visiting https://code.visualstudio.com

You will need to install the rust-analyzer extension in order to have code completion and
type hints which are absolutely needed when developing in Rust. You can find it here: https:
//marketplace.visualstudio.com/items?itemName=matklad.rust-analyzer.

1.8.3 Install Docker or Podman

Docker and Podman are two tools used to ease the management of Linux containers. They
allow us to work on clean environments and make our build and deployment processes more
reproducible.

I recommend using Docker on macOS and Windows and Podman on Linux.

The instructions to install Docker can be found on the official website: https://docs.docker.
com/get-docker

The same is true for Podman: https://podman.io/getting-started/installation

In the next chapter, we will use commands of the form:

$ docker run -ti debian:latest

If you’ve been the podman’s way, you will just have to replace the docker command by
podman .

$ podman run -ti debian:latest

or better: create a shell alias.

# in .bashrc or .zshrc
alias docker=podman

24
1.9 Our first Rust program: A SHA-1 hash cracker
The moment has come to get our hands dirty: let’s write our first Rust program. As for all
the code examples in this book, you can find the complete code in the accompanying Git
repository: https://github.com/skerkour/black-hat-rust

$ cargo new sha1_cracker

Will create a new project in the folder sha1_cracker .

Note that by default, cargo will create a binary (application) project. You can create a
library project with the --lib flag: cargo new my_lib --lib .

Figure 1.4: How a hash function works

SHA-1 is a hash function used by a lot of old websites to store the passwords of the users. In
theory, a hashed password can’t be recovered from its hash. Thus by storing the hash in their
database, a website can assert that a given user has the knowledge of its password without
storing the password in cleartext, by comparing the hashes. So if the website’s database is
breached, there is no way to recover the passwords and access the users’ data.

Reality is quite different. Let’s imagine a scenario where we just breached such a website, and
we now want to recover the credentials of the users in order to gain access to their accounts.
This is where a “hash cracker” is useful. A hash cracker is a program that will try many
different hashes in order to find the original password.

This is why when creating a website, you should use a hash function specifically designed for
this use case, such as argon2id , which require way more resource to bruteforce than SHA-1,
for example.

This simple program will help us learn Rust’s fundamentals:

• How to use Command Line Interface (CLI) arguments

• How to read files
• How to use an external library
• Basic error handling
• Resources management

25
Like in almost all programming languages, the entrypoint of a Rust program is its main
function.

ch_01/sha1_cracker/src/main.rs

fn main() {
// ...
}

Reading command line arguments is as easy as:

ch_01/sha1_cracker/src/main.rs

use std::env;

fn main() {
let args: Vec<String> = env::args().collect();
}

Where std::env imports the module env from the standard library and env::args()
calls the args function from this module and returns an iterator which can be “collected”
into a Vec<String> , a Vector of String objects. A Vector is an array type that
can be resized.

It is then easy to check for the number of arguments and display an error message if it does
not match what is expected.

ch_01/sha1_cracker/src/main.rs

use std::env;

fn main() {
let args: Vec<String> = env::args().collect();

if args.len() != 3 {
println!("Usage:");
println!("sha1_cracker: <wordlist.txt> <sha1_hash>");
return;
}
}

As you may have noticed, the syntax of println! with an exclamation mark is strange.
Indeed, println! is not a classic function but a macro. As it’s a complex topic, I redirect
you to the dedicated chapter of the Book: https://doc.rust-lang.org/book/ch19-06-macros.h
tml.

println! is a macro and not a function because Rust doesn’t support (yet?) variadic

26
generics. It has the advantage of being compile-time evaluated and checked and thus prevent
vulnerabilities such as format string vulnerabilities.

1.9.1 Error handling

How should our program behave when encountering an error? And how to inform the user of
it? This is what we call error handling.

Among the dozen programming languages that I have experience with, Rust is without any
doubts my favorite one regarding error handling due to its explicitness, safety, and conciseness.

For our simple program, we will Box errors: we will allow our program to return any type
that implements the std::error::Error trait. What is a trait? More on that later.

ch_01/sha1_cracker/src/main.rs

use std::{
env,
error::Error,
};

const SHA1_HEX_STRING_LENGTH: usize = 40;

fn main() -> Result<(), Box<dyn Error>> {

let args: Vec<String> = env::args().collect();

if args.len() != 3 {
println!("Usage:");
println!("sha1_cracker: <wordlist.txt> <sha1_hash>");
return Ok(());
}

let hash_to_crack = args[2].trim();

if hash_to_crack.len() != SHA1_HEX_STRING_LENGTH {
return Err("sha1 hash is not valid".into());
}

Ok(())
}

1.9.2 Reading files

As it takes too much time to test all possible combinations of letters, numbers, and special
characters, we need to reduce the number of SHA-1 hashes generated. For that, we use a
special kind of dictionary, known as a wordlist, which contains the most common password

27
found in breached websites.

Reading a file in Rust can be achieved with the standard library like that:

ch_01/sha1_cracker/src/main.rs

use std::{
env,
error::Error,
fs::File,
io::{BufRead, BufReader},
};

const SHA1_HEX_STRING_LENGTH: usize = 40;

fn main() -> Result<(), Box<dyn Error>> {

let args: Vec<String> = env::args().collect();

if args.len() != 3 {
println!("Usage:");
println!("sha1_cracker: <wordlist.txt> <sha1_hash>");
return Ok(());
}

let hash_to_crack = args[2].trim();

if hash_to_crack.len() != SHA1_HEX_STRING_LENGTH {
return Err("sha1 hash is not valid".into());
}

let wordlist_file = File::open(&args[1])?;

let reader = BufReader::new(&wordlist_file);

for line in reader.lines() {

let line = line?.trim().to_string();
println!("{}", line);
}

Ok(())
}

1.9.3 Crates
Now that the basic structure of our program is in place, we need to actually compute the SHA-
1 hashes. Fortunately for us, some talented developers have already developed this complex
piece of code and shared it online, ready to use in the form of an external library. In Rust,

28
we call those libraries, or packages, crates. They can be browsed online at https://crates.io.

They are managed with cargo : Rust’s package manager. Before using a crate in our
program, we need to declare its version in Cargo’s manifest file: Cargo.toml .

ch_01/sha1_cracker/Cargo.toml

[package]
name = "sha1_cracker"
version = "0.1.0"
authors = ["Sylvain Kerkour"]
edition = "2018"

# See more keys and their definitions at

↪ https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
sha-1 = "0.9"
hex = "0.4"

We can then import it in our SHA-1 cracker:

ch_01/sha1_cracker/src/main.rs

use sha1::Digest;
use std::{
env,
error::Error,
fs::File,
io::{BufRead, BufReader},
};

const SHA1_HEX_STRING_LENGTH: usize = 40;

fn main() -> Result<(), Box<dyn Error>> {

let args: Vec<String> = env::args().collect();

if args.len() != 3 {
println!("Usage:");
println!("sha1_cracker: <wordlist.txt> <sha1_hash>");
return Ok(());
}

let hash_to_crack = args[2].trim();

if hash_to_crack.len() != SHA1_HEX_STRING_LENGTH {
return Err("sha1 hash is not valid".into());
}

29
 let wordlist_file = File::open(&args[1])?;
let reader = BufReader::new(&wordlist_file);

for line in reader.lines() {

let line = line?;
let common_password = line.trim();
if hash_to_crack ==
↪ &hex::encode(sha1::Sha1::digest(common_password.as_bytes())) {
println!("Password found: {}", &common_password);
return Ok(());
}
}
println!("password not found in wordlist :(");

Ok(())
}

Hourray! Our first program is now complete. We can test it by running:

$ cargo run -- wordlist.txt 7c6a61c68ef8b9b6b061b28c348bc1ed7921cb53

Please note that in a real-world scenario, we may want to use optimized hash crackers such
as hashcat or John the Ripper, which, among other things, may use the GPU to significantly
speed up the cracking.

Another point would be to first load the wordlist in memory before performing the computa-
tions.

1.9.4 RAII
A detail may have caught the attention of the most meticulous of you: we opened the wordlist
file, but we never closed it!

This pattern (or feature) is called RAII: Resource Acquisition Is Initialization. In Rust,
variables not only represent parts of the memory of the computer, they may also own resources.
Whenever an object goes out of scope, its destructor is called, and the owned resources are
freed.

Thus, you don’t need to call a close method on files or sockets. When the variable is
dropped (goes out of scope), the file or socket will be automagically closed.

In our case, the wordlist_file variable owns the file and has the main function as
scope. Whenever the main function exits, either due to an error or an early return, the owned
file is closed.

30
Magic, isn’t it? Thanks to this, it’s very rare to leak resources in Rust.

1.9.5 Ok(())
You might also have noticed that the last line of our main function does not contain the
return keyword. This is because Rust is an expression-oriented language. Expressions
evaluate to a value. Their opposites, statements, are instructions that do something and end
with a semicolon ( ; ).

So if our program reaches the last line of the main function, the main function will
evaluate to Ok(()) , which means: “success: everything went according to the plan”.

An equivalent would have been:

return Ok(());

but not:

Ok(());

Because here Ok(()); is a statement due to the semicolon, and the main function no longer
evaluates to its expected return type: Result .

1.10 Mental models for approaching Rust

Using Rust may require you to re-think all the mental models you learned while using other
programming languages.

1.10.1 Embrace the compiler

The compiler will make you hard times when starting Rust. You will hate it. You will swear.
You will wish to disable it and send it to hell. Don’t.

The compiler should be seen as an always available and friendly code-reviewer. So it’s not
something preventing your code from compiling. Instead, it’s a friend that tells you that your
code is defective and even offers suggestions on how to fix it.

I have witnessed a great improvement over the years of the messages displayed by the compiler,
and I have no doubts that if today the compiler produces an obscure message for an edge
case, it will be improved in the future.

1.10.2 Just In Time learning

Rust is a vast language that you won’t be able to master in a few weeks. And that’s totally
fine. You don’t have to know everything to get started.

31
I’ve spent a lot of time reading about all the computer science behind Rust before even writing
my first program. This was the wrong approach. There is too much to read about all
the features of Rust, and you certainly won’t use them all (and you shouldn’t! For example,
please never ever use non_ascii_idents it will only bring chaos and pain!). All this stuff is
really interesting and produced by very smart people, but it prevents you from getting things
done.

Instead, embrace the unknown and make your first programs. Fail. Learn. Repeat.

1.10.3 Keep it simple

Don’t try to be too clever!. If you are fighting with the limits of the language (which is
already huge), it may mean that you are doing something wrong. Stop what you are doing,
take a break, and think about how you can do things differently. It happens to me almost
every day.

Also, keep in mind that the more you are playing with the limits of the type system, the
more your code will create hard-to-understand errors by the compiler. So, make you and your
co-workers a favor: KISS (Keep It Simple, Stupid).

Favor getting things done rather than the perfect design that will never ship. It’s
far better to re-work an imperfect solution than to never ship a perfect system.

1.10.4 You pay the costs upfront

Programming in Rust may sometimes appear to be slower than in Python, Java, or Go. This
is because, in order to compile, the Rust compiler requires a level of correctness far superior
to other languages. Thus, in the whole lifetime of a project, Rust will save you a lot of time.
All the energy you spend crafting a correct program in Rust, is 1x-10x the time (and money
and mental health!) you save when you won’t have to spend hours and hours debugging
weird bugs.

The first programs I shipped in production were in TypeScript (Node.js) and Go. Due to the
lax compilers and type systems of these languages, you have to add complex instrumentation
to your code and external services to detect errors at runtime. In Rust, I’ve never had to
use this. Simple logging (as we will see in chapter 4) is all I ever needed to track bugs in
my programs. Aside from that, as far as I remember, I’ve never experienced a crash in a
production system in Rust. This is because Rust forces you to “pay the costs upfront”: you
have to handle every error and be very intentional about what you are doing.

Here is another testimony from “jhgg”, Senior Staff Engineer at Discord: “We are going hard
on Rust in 2021 after some very successful projects in 2019 and 2020. our engineers have
ramped up on the language - and we have good support internally (both in terms of tools, but
also knowledge) to see its success. Once you’ve passed the learning curve - imo, Rust is far

32
easier and more productive to write than go - especially if you know how to leverage the type
system to build idiomatic code and apis that are very hard to use incorrectly. Every piece of
rust code we have shipped to production so far has gone perfectly thanks to the really powerful
compile time checks and guarantees of the language. I can’t say the same for our experiences
with go. Our reasons go well beyond”oh the gc in go has given us problems” but more like
“go as a language has willingly ignored and has rejected advances in programming languages”.
You can pry those algebraic data types, enums, borrow checker, and compile time memory
management/safety, etc… from my cold dead hands. [..]“

1.10.5 Functional
Rust is (in my opinion) the perfect mix between an imperative and a functional language
to get things done. It means that if you are coming from a purely imperative programming
language, you will have to unlearn some things and embrace the functional paradigm.

Favor iterators (chapter 3) over for loops. Favor immutable data over mutable references,
and don’t worry, the compiler will do a great job optimizing your code.

1.11 A few things I’ve learned along the way

If I had to summarize my experience with Rust in one sentence, it would be: The produc-
tivity of a high-level language with the speed of a low-level language.

Here are a few tips learned the hard way that I’m sharing to make your Rust journey as
pleasant as possible.

Figure 1.5: Rust’s learning curve

33
Learning Rust can sometimes be extremely frustrating: there are a lot of new concepts to
learn, and the compiler is mercy-less. But this is for your own good.

It took me nearly 1 year of full-time programming in Rust to become proficient and no longer
have to read the documentation every 5 lines of code. It’s a looong journey but totally worth
it.

1.11.1 Try to avoid lifetimes annotations

Lifetimes are certainly one of the scariest things for new people coming to Rust. Kind of like
async , they are kind of viral and color functions and structures which not only make your
code harder to read but also harder to use.

// Haha is a struct to wrap a monad generator to provide a facade for any kind of
↪ generic iterator. Because.
struct Haha<'y, 'o, L, O>
where for<'oO> L: FnOnce(&'oO O) -> &'o O,
O: Trait<L, 'o, L>,
O::Item : Clone + Debug + 'static {
x: L,
}

Yeaah suure, please don’t mind that somebody, someday, will have to read and understand
your code.

But lifetimes annotations are avoidable and, in my opinion should be avoided. So here is
my strategy to avoid turning Rust code into some kind of monstrosity that nobody will ever
want to touch and slowly die of disregard.

1.11.1.1 Why are lifetime annotations needed in the first place?

Lifetime annotations are needed to tell the compiler that we are manipulating some kind of
long-lived reference and let him assert that we are not going to screw ourselves.

1.11.1.2 Lifetime Elision

The simplest and most basic trick is to omit the lifetime annotation.

fn do_something(x: &u64) {
println!("{}", x);
}

It’s most of the time easy to elide input lifetimes, but beware that to omit output lifetime
annotations, you have to follow these 3 rules:

• Each elided lifetime in a function’s arguments becomes a distinct lifetime parameter.

34
 • If there is exactly one input lifetime, elided or not, that lifetime is assigned to all elided
lifetimes in the return values of that function.
• If there are multiple input lifetimes, but one of them is &self or &mut self, the lifetime
of self is assigned to all elided output lifetimes.

Otherwise, it is an error to elide an output lifetime.

fn do_something(x: &u64)-> &u64 {

println!("{}", x);
x
}

// is equivalent to
fn do_something_else<'a>(x: &'a u64)-> &'a u64 {
println!("{}", x);
x
}

1.11.1.3 Smart pointers

Now, not everything is as simple as an HelloWorld and you may need some kind of long-
lived reference that you can use at multiple places of your codebase (a Database connection,
for example, or an HTTP client with an internal connection pool).

The solution for long-lived, shared (or not), mutable (or not) references is to use smart point-
ers.

The only downside is that smart pointers, in Rust, are a little bit verbose (but still way less
ugly than lifetime annotations).

use std::rc::Rc;

fn main() {
let pointer = Rc::new(1);

{
let second_pointer = pointer.clone(); // or Rc::clone(&pointer)
println!("{}", *second_pointer);
}

println!("{}", *pointer);
}

35
1.11.1.3.1 Rc To obtain a mutable, shared pointer, you can use use the interior muta-
bility pattern:

use std::cell::{RefCell, RefMut};

use std::rc::Rc;

fn main() {
let shared_string = Rc::new(RefCell::new("Hello".to_string()));

{
let mut hello_world: RefMut<String> = shared_string.borrow_mut();
hello_world.push_str(" World");
}

println!("{}", shared_string.take());
}

1.11.1.3.2 Arc Unfortunately, Rc<RefCell<T>> cannot be used across threads or in

an async context. This is where Arc comes into play, which implements Send and
Sync and thus is safe to share across threads.

use std::sync::{Arc, Mutex};

use std::{thread, time};

fn main() {
let pointer = Arc::new(5);

let second_pointer = pointer.clone(); // or Arc::clone(&pointer)

thread::spawn(move || {
println!("{}", *second_pointer); // 5
});

thread::sleep(time::Duration::from_secs(1));

println!("{}", *pointer); // 5
}

For mutable shared variables, you can use Arc<Mutex<T>> :

use std::sync::{Arc, Mutex};

use std::{thread, time};

fn main() {
let pointer = Arc::new(Mutex::new(5));

36
 let second_pointer = pointer.clone(); // or Arc::clone(&pointer)
thread::spawn(move || {
let mut mutable_pointer = second_pointer.lock().unwrap();
*mutable_pointer = 1;
});

thread::sleep(time::Duration::from_secs(1));

let one = pointer.lock().unwrap();

println!("{}", one); // 1
}

Smart pointers are particularly useful when embedded into structures:

struct MyService {
db: Arc<DB>,
mailer: Arc<dyn drivers::Mailer>,
storage: Arc<dyn drivers::Storage>,
other_service: Arc<other::Service>,
}

1.11.1.4 When to use lifetimes annotations

In my opinion, lifetimes annotations should never surface in any public API. It’s okay to
use them if you need absolute performance AND minimal resources usage AND are doing
embedded development, but you should keep them hidden in your code, and they should
never surface in the public API.

1.11.2 It can be easy to write hard-to-read and debug code

Due to its explicitness and its bunch of features, Rust code can quickly become hard to
understand. Generics, trait bounds, lifetimes… It’s easy not to pay attention and write very
hard-to-read code. My advice is to always think twice before writing complex code or a macro
(for me, they are the worst offenders) that can easily be replaced by a function.

1.11.3 Fast-paced development of the language

It’s the point that scares me the most regarding Rust’s future. Every 6 weeks a new version
is released with its batch of new features.

Not only this pace causes me anxiety, but it is also the opposite of one of the pillars of my
life: minimalism, where it is common knowledge that unbounded growth (of the language in
this case) is the root cause of the demise of everything. When something is added, something

37
must be subtracted elsewhere. But who is in charge of removing Rust’s features? Is it even
possible?

As a result, I’m afraid that the complexity of the language will grow faster than its rate of
adoption and that it will be an endless, exhausting race to stay updated on the new features
as developers.

1.11.4 Slow compile times

Compile times are closer to what we can find in the C++ world than in the world of dynamic
languages like TypeScript (if TypeScript can be considered as a dynamic language). As a re-
sult, the “edit, compile, debug, repeat” workflow can become frustrating and break developers
flow.

There are many tricks to improve the compilation speed of your projects.

The first one is to split a large project into smaller crates and benefit from Rust’s incremental
compilation.

Another one is to use cargo check instead of cargo build most of the time.

$ cargo check

As an example, on a project, with a single letter change:

$ cargo check
Finished dev [unoptimized + debuginfo] target(s) in 0.12s

cargo build
Compiling agent v0.1.0 (black-hat-rust/ch_11/agent)
Finished dev [unoptimized + debuginfo] target(s) in 2.24s

Compounded over a day (or week or month) of development, the gains are huge.

Finally, simply reduce the use of generics. Generics add a lot of work to the compiler and
thus significantly increase compile times.

1.11.5 Projects maintenance

It’s an open secret that most of the time and costs spent on any serious software project are
from maintenance. Rust is moving fast, and its ecosystem too, it’s necessary to automate
projects’ maintenance.

The good news is that, in my experience, due to its strong typing, Rust project maintenance
is easier than in other languages: errors such as API changes will be caught at compile time.

38
For that, the community has built a few tools which will save you a lot of time to let you keep
your projects up to date.

1.11.5.1 Rustup

Update your local toolchain with rustup :

$ rustup self update

$ rustup update

1.11.5.2 Rust fmt

rustfmt is a code formatter that allows codebases to have a consistent coding style and
avoid nitpicking during code reviews.

It can be configured using a .rustfmt.toml file: https://rust-lang.github.io/rustfmt.

You can use it by calling:

$ cargo fmt

In your projects.

1.11.5.3 Clippy

clippy is a linter for Rust. It will detect code patterns that may lead to errors or are
identified by the community as bad style.

It helps your codebase to be consistent and reduce time spent during code reviews discussing
tiny details.

It can be installed with:

$ rustup component add clippy

And used with:

$ cargo clippy

1.11.5.4 Cargo update

$ cargo update

Is a command that will automatically update your dependencies according to the semver
declaration in your Cargo.toml .

39
1.11.5.5 Cargo outdated

cargo-outdated is a program that helps you to identify your outdated dependencies that
can’t be automatically updated with cargo update

It can be installed as follows:

$ cargo install -f cargo-outdated

The usage is as simple as running

$ cargo outdated

In your projects.

1.11.5.6 Cargo audit

Sometimes, you may not be able to always keep your dependencies to the last version and
need to use an old version (due to dependency by another of your dependency…) of a crate.
As a professional, you still want to be sure that none of your outdated dependencies contains
any known vulnerability.

cargo-audit is the tool for the job. It can be installed with:

$ cargo install -f cargo-audit

Like other helpers, it’s very simple to use:

$ cargo audit
Fetching advisory database from `https://github.com/RustSec/advisory-db.git`
Loaded 317 security advisories (from /usr/local/cargo/advisory-db)
Updating crates.io index
Scanning Cargo.lock for vulnerabilities (144 crate dependencies)

1.11.6 How to track your findings

You will want to track the progress of your audits and the things you find along the way,
whether it be to share with a team or to come back later.

There are powerful tools such as Maltego (more about it in chapter 5), but it can become
costly if you want all the features.

On my side, I prefer to use simple files on disk, with markdown to write notes and reports and
Git for the backup. It has the advantage of being extremely simple to use, multi-platform,
easily exported, and free. Also, it easy to generate PDFs, .docx or other document formats
from the markdown files using pandoc.

40
I’ve also heard good things about Obsidian.md and Notion.so but personally don’t use: I
prefer to own my data ��

1.12 Summary
• The Rust language is huge. Don’t learn everything ahead of time. Code. Fail. Learn.
Repeat.
• Expressions evaluate to a value. Their opposites, statements, are instructions that do
something and end with a semicolon ( ; ).
• Try not to use lifetime annotations and macros.
• Embrace the compiler. It should be seen as an always present and friendly code-
reviewer.
• RAII: Resource Acquisition Is Initialization.
• The hacker, The exploit writer, The developer, The system administrator, The analyst
• Reconnaissance, Exploitation, Lateral Movements, Data exfiltration, Clean up

41
Chapter 2

Multi-threaded attack surface

discovery

“To know your Enemy, you must become your Enemy”, Sun Tzu

As we have seen, the first step of every attack is reconnaissance. The goal of this phase is to
gather as much information as possible about our target in order to find entry points for the
coming assault.

In this chapter, we will see the basics of reconnaissance, how to implement our own scanner
in Rust and how to speed it up by leveraging multithreading.

There are two ways to perform reconnaissance: Passive and Active.

Figure 2.1: Passive vs Active reconnaissance

2.1 Passive reconnaissance

Passive reconnaissance is the process of gathering information about a target without inter-
acting with it directly, for example, searching for the target on different social networks and
search engines.

Using publicly available sources is called OSINT, for Open Source INTelligence.

42
What kind of data is harvested using passive reconnaissance? Usually, pieces of information
about employees of a company such as names, email addresses, phone numbers, but also
source code repositories, leaked tokens. Thanks to search engines like Shodan, we can also
look for open-to-the-world services and machines.

As passive reconnaissance is the topic of chapter 5, we will focus our attention on active
reconnaissance in this chapter.

2.2 Active reconnaissance

Active reconnaissance is the process of gathering information about a target directly by inter-
acting with it.

Active reconnaissance is noisier and can be detected by firewalls and honeypots, so you have
to be careful to stay undetected, for example, by spreading the scan over a large span of time.

A honeypot is an external endpoint that shall never be used by “regular” people of a given
company, so the only people hitting this endpoint are attackers. It can be a mail server, an
HTTP server, or even a document with remote content embedded.

Once a honeypot is scanned or hit, it will report back to the security team which put it in
place.

A canary is like a honeypot but in an internal network. Its purpose is to detect attackers once
they have breached the external perimeter.

The reconnaissance of a target can itself be split into two steps:

• Assets discovery
• Vulnerabilities identification (which is the topic of chapter 6)

2.3 Assets discovery

Traditionally, assets were defined only by technical elements: IP addresses, servers, domain
names, networks…

Today the scope is broader and encompasses social network accounts, public source code
repositories, Internet of Things objects… Nowadays, everything is on or connected to the
internet. From an offensive point of view, it’s really interesting.

The goal of listing and mapping all the assets of a target is to find entry points and vulnera-
bilities for our coming attack.

43
Exploring the Variety of Random
Documents with Different Content
affairs of Muscotah. He is a director and stockholder in the State
Bank at Muscotah, Kan., and has an interest in the Farmers’ Grain
and Elevator Supply Company and the Mutual Telephone Company.
In 1903 he married Jane Ernst, who was born November 6, 1871,
in Kapioma township, Atchison county. She is a daughter of John
and Eliza (Lewis) Ernst. The father is a native of Germany and the
mother of Norway, and both came to Atchison county, Kansas, in the
early days. Mr. and Mrs. Miller have two children: Alice E. and Mary
E., twins, who are living at home. Mr. Miller is a Democrat and has
been treasurer of Kapioma township. He is a member of the Ancient
Free and Accepted Masons.
 CHARLES CARLTON HART.
For a Kansas citizen and pioneer settler to spend the better part
of a lifetime in building up a fine and highly productive farm, and
then to enter the banking business at a time when most men are
ready to retire and live a life of ease, is rather out of the ordinary, but
such has been the experience of C. C. Hart, banker, of Muscotah,
Kan. Mr. Hart has lived in Kansas for forty-seven years and has been
successively farmer and banker during that time. He is a descendant
of one of the old families in America and comes of a family of
ministers and teachers.

C. C. Hart

C. C. Hart was born December 6, 1842, in Sandusky, Ohio, and

was a son of Rev. Ichabod and Harriet (Whitcomb) Hart, the former
a native of New York, and the latter was born in Templeton, Mass.,
April 22, 1819, and died in Chicago, Ill., April 30, 1889. The Hart
family is a very old one in America and is descended from two
English immigrants who settled in Connecticut in the colonial period
of our Nation’s history, and from whom the city of Hartford took its
name in the seventeenth century. Several descendants of these early
pioneers fought for the cause of American independence in the
American Revolution and also in the War of 1812. Two brothers of C.
C. Hart served in the Union army in the late Civil war. The father of
C. C. Hart was educated for the Presbyterian ministry and later
became a Congregational minister. He received his college training in
Princeton University and migrated to Ohio in 1840; resided at
Sandusky until 1843, and then took charge of a church at Medina,
Ohio, until 1844, when he removed to Kenosha, Wis. After several
years’ ministerial work in Wisconsin he located in Illinois, and died
at Wheaton, that State, in 1870, at the ripe old age of eighty-four
years. Rev. Hart was the father of eight children: Edwin R. received a
college education and served in the Union army; Rev. Walter O.
Hart, a Union veteran, now located in North Carolina; Eliza born in
Kenosha, Wis., January 23, 1847, married George W. Phillips, and
died September 15, 1875, at Llano, Texas, one and one-half years
after her marriage. While carrying on his ministerial work the Rev.
Ichabod Hart also conducted a farm in the neighborhood of his work.
Edwin R. Hart was educated in Oberlin College, Ohio, and Walter O.
received a college and theological institute education and is now
living in retirement with his son who also is a minister.
C. C. Hart, with whom this review is directly concerned, was
reared to young manhood on his father’s farm and attended the
schools of Genoa, Wis. During the Civil war lie remained at home
and assisted his father in the farm work. In 1868 he decided to strike
out for himself and try his fortunes in the West. He came to Kansas
and located in Jackson county, on the western border of Atchison
county, where he purchased 160 acres of railroad owned land, at a
cost of five dollars and forty cents per acre. He at once began
improving this tract which was raw prairie at the time of purchase
and in the course of time developed it into a fine and highly
productive farm. The Hart farm is one of the most productive and
best improved in the State of Kansas and is widely known for the
excellent shape in which the grounds and improvements are kept.
Mr. Hart added eighty acres adjoining in Atchison county to the
original quarter section and now has 240 acres in all. He remained
on the farm until 1905, in the meantime having become interested in
the Muscotah State Bank as a stockholder and director. In that year
he removed to the town of Muscotah, where he has since made his
residence in an attractive home. Mr. Hart was elected cashier of the
bank January 1, 1910, and served in this capacity until August 1, 1915.
While cashier he also served as vice-president of the institution and
is now connected with the bank in that capacity.
Mr. Hart was married in 1867 to Miss Emma A. Olden, who has
borne him the following children: Arthur C., born in 1873, married
Bertie Stockton, and has one child, Dorothy, residing in Bakersfield,
Cal.; Dwight Hart died in youth. Mrs. Emma A. (Olden) Hart, the
mother, was born in Wisconsin in 1846, and is a daughter of Enos
Olden, a native of New York State, and a descendant of an old
eastern family.
The Republican party has always claimed the allegiance of Mr.
Hart, and he has taken an active part in political affairs during his
long residence in Grasshopper township and Muscotah. While living
on the farm he held various township offices, and was always found
in the forefront of civic movements which had for their intention the
ultimate good of all the people. He filled the post of mayor of
Muscotah for four years and was a good official. In church work he
has been very active and is at present the treasurer of the
Congregational church. His work in the interest of the young people
of Muscotah has endeared him to all of the residents and for twenty-
five years he has served as the superintendent of the Sunday school
of his church. Mr. Hart was secretary of the Atchison County Sunday
School Association for ten years. Although this grand old pioneer has
passed the allotted three score and ten years of age. He is still active,
mentally and physically, and rarely a day passes which does not find
him at his desk attending to his duties in the bank or working about
the grounds of his attractive, well kept home. Mr. Hart is a courteous
and kindly gentleman of the old school whom one can not help but
admire for his many sterling qualities.
 WILLIAM YOUNG.
A native born Kansan, who became a successful agriculturist and
banker, and left an indelible imprint upon the business and social life
of Atchison county, was the late William Young, of Arrington, Kan.
The Young family was one of the real pioneer families of the county,
and the late Mr. Young was born on a pioneer farm in Mt. Pleasant
township May 20, 1858. He was a son of William Johnson Young,
whose wife was Mrs. Martha (Wamach) Snowden, widow, born in
Virginia, a daughter of Abraham Wamach, an early pioneer settler of
Atchison county, who came to this county in 1854 and settled on
adjoining homesteads with W. J. Young. W. J. Young, the father of
William, was born in Tennessee in 1815, and was the first judge of
Atchison county. He settled on a farm in Walnut township, two and
one-half miles northeast of Potter, Kan., which farm is now owned by
Peter C. Griner. The elder Young was a natural born leader of men,
and took an active and influential part in the political affairs of the
county in the early days. He was a religious man, whose home was a
meeting place for the politicians and ministers of the Gospel, and he
was very hospitable. His father was the Rev. Duke Young, a native of
Tennessee, who came to Kansas in 1854, and preached the first
sermon in the county, on the doctrine of the Christian denomination.
The Rev. Mr. Young was about sixty years of age when he came to
Atchison county, and he had been preaching the Gospel for many
years in Tennessee. J. W. Young became a member of the Christian
church when sixteen years of age. The Young family was of Scotch-
Irish ancestry.
William Young, with whom this review is directly concerned,
was one of a family of fourteen children reared by his parents. He
grew to manhood on his father’s farm, and after his marriage, in
1880, he and his wife located on a farm in Mt. Pleasant township,
near the town of Potter, and developed it into a fine and productive
tract. He continued in agricultural pursuits until 1908, when he went
to Arrington, Kan., and purchased the Arrington State Bank, which
he operated until his demise, January 12, 1910. After Mr. Young’s
death, his widow disposed of the bank and the Arrington property,
and removed to Atchison, where she has since made her home at 419
Kearney street.
William Young was married February 5, 1880, to Miss Angie
Cooley, and to this union were born the following children: Maude,
wife of Earl Stapler, Atchison; Duff D. Young, born April 8, 1901. The
mother of these children was born November 9, 1861, a daughter of
James and Cassendania (Waddle) Cooley, both of whom were born
and reared in Kentucky. James Cooley, her father, migrated to
Kansas in 1854 and settled on a homestead south of Potter, in
Leavenworth county. His wife, Cassendania, came to Kansas to
reside with her sister, Mrs. Masterson, who lived in Mt. Pleasant
township, and she was married in 1860 to James Cooley. Eight
children were born to them, of whom Mrs. Young was the fifth in
order of birth. James Cooley took an active and prominent part in
political affairs in Kansas in the early days, and served as the
representative to the State legislature from Leavenworth county for
two terms, from 1868 to 1872, inclusive. He died in 1876.
William Young was a member of the Ancient Free and Accepted
Masons, the Odd Fellows, and the Fraternal Aid Union. He was a
man who lived his life according to Christian precepts, and was a
regular attendant at church and Sunday school of the Christian
denomination. His start in life was at the foot of the ladder, and he
was successful in his undertakings, building for himself and his
family, and leaving behind him on this earth the memory of a life
well spent, and to his family a heritage of industry, honesty,
straightforwardness and right living which will long be remembered
by those who knew him best.
 JAMES E. BEHEN.
In the compilation of the biographical department of this history
of Atchison county, Kansas, the fact is frequently brought to the
mind of the reviewer that the really successful men of this county are
essentially self-made, and began at the foot of the ladder of success,
working their way upward by various means, all of which were
honest and based upon hard and painstaking labor at the outset of
their careers. Very few were well educated, or had been blessed with
opportunities in their youth such as are the heritage of the youth of
the present day. James Edward Behen, successful farmer, of Center
township, Atchison county, is one of those citizens who are deserving
of credit for what they have accomplished. Starting out as a boy of
twelve, he has made his own way in the world, and after he attained
manhood, with the assistance of a good and faithful helpmeet, he has
accomplished results which are really creditable. Starting with a tract
of eighty acres of land in 1900, which he found necessary to improve,
he soon added another eighty, then another eighty, and now has a
fine farm of 240 acres, which is one of the most fertile tracts of land
in the county, practically all of which is in cultivation. Mr. Behen has
the right idea of farming, inasmuch as he sells the product of his
farm “on the hoof,” and has become an extensive feeder of cattle and
hogs. This plan insures the fertility of the soil, and his farm is
steadily improving as the result of a wise method of cultivation.
Mr. Behen is a native son of Kansas, who was born and brought
up on Kansas soil, and will not admit that there is any better place
under the sun for a man to acquire a fortune than right here in
Atchison county, and, judging by what he has done in Kansas, the
writer is prone to agree with him. James E. Behen was born March
28, 1864, at Leavenworth, and is a son of Michael and Mary Behen,
who had six children. The father was of Irish descent. He followed
bridge building. James, the subject of this sketch, started out to make
his own way at the age of twelve years, and went to work on the farm
of Edward Whalen, in Doniphan county, Kansas, and stayed there
eight years. Meanwhile, he attended the district school, receiving a
rudimentary education. He then worked as a farm hand until he was
twenty-two years old. For several years following he rented land in
Atchison and Doniphan counties. In 1900 he bought eighty acres in
Center township, and five years later bought the eighty acres
adjoining his farm on the west. Now he owns 240 acres, which he has
improved considerably. He built a modern barn, 32×35 feet in size,
and also built a fine cattle barn, forty feet square. He does a large
feeding business, handling a carload of cattle each year. He keeps
graded stock of all kinds on his farm.
In 1888 he was married to Lizzie Pauly, who was born March 30,
1862, in Doniphan county, Kansas. She is the daughter of John and
Anna (Hartzinger) Pauly, natives of Germany. The parents were early
settlers in Illinois, and moved to Doniphan county, Kansas, in 1857.
Mr. and Mrs. Behen have eight children: Mrs. Agnes McCibben,
Atchison, Kan.; Alice, deceased; Mary, graduate of Atchison High
School, living at home; Thomas, living at home; Joseph, at home;
John, whereabouts unknown; Roy and Fred, living at home. Mr.
Behen is a Democrat. He is a member of the Roman Catholic church.
 FRED HARTMAN.
It is meet that considerable space be devoted to the valiant old
pioneers of Kansas who assisted in the settlement of the country, and
had much to do with its development. Not all of them figured
prominently, and it was given to a very few to be honored above their
fellows. In the latter class the reviewer must of necessity and choice
place the late Fred Hartman, pioneer, successful farmer, Union
veteran and well known public official, who for more than two
decades was a well known and highly esteemed citizen of Atchison
county.
Fred Hartman was born in Franklin county, Indiana, December
7, 1844, a son of Jonathan and Christina (Wolking) Hartman. His
paternal grandfather was Henry Hartman, a native of Pennsylvania,
of German extraction, and his wife, Alice Case, whom he married in
Pennsylvania, migrated to Indiana in the early days of the settlement
of the Hoosier State. Jonathan Hartman, father of the subject, was
born in Franklin county, Indiana, January 22, 1822, and was reared
to young manhood among the rugged hills of his native county,
learning the carpenter’s trade, and then moving to Platte county,
Missouri, with his family in 1846. Nine years after settling in Platte
county, he removed to Port William, at that time a thriving
settlement on the banks of the Missouri river in Atchison county.
Here he erected one of the first sawmills in Atchison county and the
State of Kansas, and furnished all the sawed lumber for the settlers
for many miles around. The year 1856 saw the beginning of the
struggle between the Free State and pro-slavery men for possession
of Kansas, and the summer of that year witnessed some lively times.
History records the fact that a man named Bob Gibson, leader of the
Kickapoo Rangers, came from the headquarters of the gang with a
squad of men for the purpose of mobbing Jonathan Hartman on
account of his opposition to slavery. Mr. Hartman was a man of high
courage and assumed a defiant attitude toward the Rangers who
finally left without doing the damage which they had boasted was
their intent. About this time the noted Pardee Butler was set afloat
on a raft down the Missouri river by the pro-slavery men of Atchison,
and Butler appealed to Hartman for aid after landing, near Port
William. Mr. Hartman gave Butler every assistance possible, in
getting him to his home. In 1857 Jonathan Hartman sold his sawmill
and settled on a farm in Mt. Pleasant township, near the old military
road which ran from Ft. Leavenworth to Denver, and the Far
Western points. Great trains of thirty or more heavily laden wagons
drawn by six and twelve yoke of oxen were constantly passing the
home of the Hartmans. Mrs. Hartman recalls the great drought of
1860 and the great snows of the following winter. During the year of
the great drought the settlers did not raise any crops and were forced
to journey to Atchison for provisions, on the return trip stopping at
the Andrew Parnell farm for assistance in their dire need. Two of the
drivers on a wagon train that terrible winter had their feet frozen,
one of the men afterwards losing both feet as a result of the
hardships undergone. The Parnell home was a welcome and
hospitable place of refuge for the starving and suffering settlers,
during that winter. Mrs. Hartman also recalls the beautiful and
inspiring sights made by the troops of United States cavalry which
were frequently seen from her home in those days.
Fred Hartman hearkened to the call of the Union in the second
year of the great civil conflict and enlisted in Company F, of the
famous Thirteenth Kansas volunteer regiment, under Captain Hayes,
Major Woodworth and Colonels Bowen and Speck. He was engaged
chiefly in scout duty, and was stationed at Ft. Smith and other points
in the Southwest during his term of service, which lasted for three
years, and was finally mustered out at Ft. Leavenworth in 1865. He
then came home and resumed the farm work on his father’s farm. He
was married January 21, 1866, to Cynthia Parnell. To this union were
born the following children: Henrietta, wife of R. H. Ripple, died in
1896; Hannah Ann, wife of James Iddings, both of whom are
deceased, and who left one child, Geneva Iddings, of Topeka, Kan.;
Dora, wife of Joseph Speck, died in 1896, leaving one daughter,
Dora, who lives with her grandmother; Jonathan, a salesman of
Kansas City; Josephine, wife of John Putman, of Atchison; May
Florence, wife of Roy Trimble, sheriff of Atchison county, has four
children; Birdie, wife of Henry Barr, died in 1906; Frederick, died in
1911, was married to Blanche Baker, daughter of Captain Baker. The
mother of these children was born January 14, 1849, in Buchanan
county, Missouri, a daughter of Andrew and Mirah (Wilson) Parnell
natives of Kentucky and Indiana, respectively. Andrew and Mirah
Parnell began their wedded life in Franklin county, Indiana, where
they were reared and then migrated to Arkansas, and from there to
Missouri in the early forties. In 1859 the family left Buchanan county
and settled in Mt. Pleasant township, Atchison county, where they
figured prominently in the early history of the county. The little
Parnell was named after Andrew Parnell and the old town of the
same name took its appellation from the family which settled in the
neighborhood. Mr. Parnell spent his last days in Jefferson county,
Kansas, where he died in 1872. He became very well-to-do and
prospered. He was one of the original Free State men and suffered
considerable loss at the hands of the Jayhawkers and border ruffians.
Andrew Parnell was the father of eleven children, six sons and five
daughters, and sent three of his sons to serve their country in the
Thirteenth Kansas regiment, one son being killed. Mrs. Hartman is
the youngest child of this large family.
When Mr. and Mrs. Fred Hartman were married they settled on
a farm near Parnell, which Mrs. Hartman still owns. They developed
this farm and cultivated it successfully until 1896, when they
removed to Atchison, where Mr. Hartman died October 25, 1909.
Mr. Hartman was a life-long Republican and began taking an active
part in political and civic affairs when he had attained his majority.
He was elected sheriff of the county in the fall of 1895, and served
four years in all, in this important office. Previous to his removal to
Atchison, he had capably filled the office of trustee of Mt. Pleasant
township. He became identified with the civic life of Atchison and
served as a member of the city council and was held in high esteem
for his ability and capabilities as a citizen. Mr. Hartman was
prominent in Odd Fellow and Masonic circles during his long life in
the county.
Fred Hartman was one of those pioneer citizens of Atchison
county which are distinguished for their qualities of leadership, and
his descendants are proud of his record as a citizen and public
official. He was, during his whole life, a reader and student who
believed in keeping abreast of the times and made a hobby of
gathering historical data, being much interested in the history of his
adopted State. His mind remained keen to the end of his days and he
will always be fondly remembered by those who knew him. To him
and his comrades who laid the foundation of the prosperous and
happy community of Atchison, this volume is respectfully dedicated.
 OSCAR A. SIMMONS.
Successful banking calls for qualifications somewhat different
from those required in other pursuits or professions. It calls for a
keen mind, decisive action, ability to pass judgment upon a
proposition and its merits, and the power to judge and gauge human
nature, and determine upon the honesty or sincerity of those with
whom the banker is constantly doing business. Oscar A. Simmons,
active vice-president and manager of the First National Bank of
Atchison, possesses the qualifications of a successful banker to a
considerable degree. He is unquestionably one of the rising
financiers of Kansas with an ever increasing prestige in financial
circles. He is one of those broad-minded men who keep abreast of
progress and have the faculty of adapting their capabilities to the
advanced needs of the times. Although a comparatively young man,
as years measure a man’s age, his experience in banking has been
such as to eminently fit him for the important position which he
holds.
 O A Simmons

O. A. Simmons is a native of Kansas, and was born in Jefferson

county February 11, 1874. His father was Joshua Simmons, a native
of Indiana, and his mother was Susan Pitcher Simmons, born and
partly reared in Missouri. The parents of both Joshua and Susan
Simmons were among the pioneer settlers in Jefferson county, and it
is probable that they located there in about 1855. Both the Simmons
and Pitcher families were prominent in the affairs of Jefferson
county in the early days of the county’s growth, and were highly
respected. Joshua Simmons and Susan Pitcher were married in
Jefferson county. At the outbreak of the Civil war, Joshua Simmons
offered his services in behalf of the Union, and enlisted in Company
A, Eleventh regiment, Kansas infantry, at the age of seventeen years,
and was under the command of Colonels Moonlight and Plumb. Mr.
Simmons took part in some hard campaigns during his enlistment,
the Eleventh regiment being a part of the division which fought
General Price’s army of invasion throughout Missouri and Arkansas.
On a number of occasions he showed his personal bravery in
volunteering for scout duty in the Southwest. He was mustered out at
the close of the war, returned home, and was married shortly
afterward. After a long and successful career as a farmer and
merchant, he is now living a retired life at Brondon, Colo., at the ripe
age of seventy-one years. Eight children were born to Joshua and
Susan Simmons, five of whom are living, as follows: Mrs. J. W.
Faubion, of Anthony, Kan.; Oscar A.; Mrs. P. H. Scales, of
Birmingham, Ala.; W. C. and C. T. Simmons, of Los Angeles, Cal. The
mother of these children departed this life in 1886. She was a good
wife and a kind and loving mother.
O. A. Simmons attended the common and high schools of his
native county and town, after which he was employed in a general
store at Winchester, Jefferson county, until 1899. He was then
employed in charge of the gents’ furnishing department of a large
department store at Leavenworth for one year. His ambitions had
always been headed toward entering the field of banking, inasmuch
as he believed that he could make a success as a banker. Opportunity
naturally beckoned; he saw the need of a bank in the town of Potter,
Atchison county. Taking what funds he could muster he went to
Potter and organized the Potter State Bank, serving as the cashier of
this institution for two years. He then sold his holdings in the Potter
bank and organized the Exchange State Bank at Nortonville. For a
period of five years he was in charge of this flourishing bank, and
here had the opportunity of demonstrating his inherent ability as a
financier. A wider and larger field beckoned to him and he came to
Atchison in 1906. Here his genius as an organizer has had full
opportunity for exercise and he organized the Commercial State
Bank, which later bought control of, and was consolidated with, the
First National of Atchison. Mr. Simmons was elected vice-president
of the bank at the time of the reorganization and was installed as the
bank manager. He has since taken an active part in the organization
of other banking concerns, having organized the Farmers State Bank
of Anthony, Kan., in 1910, of which his brother-in-law, J. W.
Faubion, is the cashier. In 1901 he organized the Jarbalo State Bank
at Jarbalo, Kan., of which T. J. Mains is cashier. Mr. Simmons
disposed of his interests in the Jarbalo bank in 1911, and bought the
Farmers State Bank at Effingham, selling control of this bank in
1912. His next venture was the purchase of the controlling interest in
the State Savings Bank at Leavenworth, of which Mr. Mains is now
the vice-president. He reorganized the Arrington State Bank at
Arrington, Kan., in 1903, and is still interested in its affairs. He
organized the Citizens State Bank at Elmo, Mo., in 1913, and is the
principal owner of this bank, and a stockholder in the Union State
Bank at McLouth, Kan. It is a noteworthy fact that every financial
institution with which Mr. Simmons has been connected has
prospered, and is in sound condition. In every bank in which he has
been interested he has displayed ability of a high order as a financier
and manager.
Mr. Simmons has been twice married, his first wife being
Margaret Mains, whom he espoused in 1902, being a daughter of
James Mains, of Oskaloosa, Kan. She died in 1907. His second
marriage, in 1910, was with Mary Frances, daughter of J. H. Barry, a
substantial and well known citizen of Atchison (see biography of J.
H. Barry). Two children have blessed this union: John Barry, born
December 17, 1911, and O. A. Simmons, junior, born March 9, 1913.
From farmer boy to banker and capitalist in the short period of a
little over forty years, with no initial capital to begin with, but a keen
mind and strong body, is the gist of the career of him of whom this
review is written. When a boy he worked for fifty cents per day in
Jefferson county. Coming from the soil, and being reared on the
farm, he has never entirely lost a love for the land itself, and is
heavily interested in various tracts of good farm land, and owns 400
acres of Atchison county farm land, and 700 acres in eastern
Colorado, which, together with holdings in Missouri and Texas, will
aggregate over 1,500 acres. His financial interests are varied, and in
Atchison are of such nature as to be of distinct benefit to the welfare
of the city. He holds stock in several of the city’s leading mercantile
concerns. His first work was as a farm laborer at $10 per month. His
commercial career practically began in a general store at Winchester,
Kan., at a salary of $17 per month, and during the twenty-three years
following, he has amassed a fortune of over $100,000. Yet, there are
those who say that opportunity for attaining wealth and position are
gone, and that a young man has no chance to succeed because of the
great competition of the financial trusts of the country. The life story
of O. A. Simmons is a direct contradiction to the wail of the
pessimist, and furnishes a decided inspiration to any young fellow
blessed with mentality and strength to go and do likewise in his
favorite line of endeavor. While Mr. Simmons is a stanch Republican,
he does not take an active part in political affairs, and has declined
political preferment.
 H. B. WALTER.
H. B. Walter, of Benton township, Atchison county, Kansas, is
one of the most widely known and successful live stock breeders in
Kansas, and has made a signal success as a breeder of Poland China
hogs during the past ten years. He first began the breeding of fine
live stock in Republic county, Kansas, and while he has been a
resident of Atchison county only since 1909, he has become known
the length and breadth of the county for his fine live stock
production. Mr. Walter did not venture in the breeding department
of specialized agriculture for the purpose of producing show animals,
but began his work purely as a commercial venture, and has
succeeded even beyond his most sanguine expectations. He is the
owner of 160 acres of fine farm land, located three and one-half miles
northwest of Effingham, on which are excellent improvements. His
farm is headquarters for supplying breeders with registered stock in
all parts of the country, and he has the distinction of having
developed the world beater of big type litters, and has produced and
sold a world’s record type of Poland China swine of the big variety.
For the past four years he has made the sales record for the State of
Kansas in the numbers produced and the prices obtained. His farm
produces 200 head of registered Big Type Poland China swine
annually, and he holds two sales each year, in the months of October
and February. In February of 1915, Mr. Walter sold fifty head of hogs,
at an average price of sixty dollars per head, to buyers who attended
the sale from all parts of the West. In February of the preceding year
he sold at his regular sale fifty head, which brought an average price
of seventy dollars each. The output of his breeding pens is shipped to
points as far west as Oregon, and to places ranging from Minnesota
to the Gulf States. In July of 1915 he filled an order for three high
priced hogs sent in from Connecticut. He has done no exhibiting
except at the local stock shows.
H. B. Walter was born on a farm in Jay county, Indiana, July 31,
1871, a son of Thomas S. and Sarah (Sherman), the former a native of
Indiana, and the latter a native of Ohio. The family migrated from
Indiana to Republic county, Kansas, in 1892, and settled on a farm in
that county, where Thomas S. still resides. H. B. received his
education in the public schools of his native county and State, and
studied at Ridgeville College, Indiana. He prepared himself for the
teaching profession, and taught school in Indiana for one year, and
taught for nine years in Republic county, after moving to Kansas. He
held the highest average grade possible to obtain in his teacher’s
certificate, and met with considerable success in his profession, but
abandoned teaching to engage in farming, in which avocation he
began with the same determination to succeed as he had been
imbued with when he began to teach. He purchased a farm in
Republic county, which he cultivated, later buying a place in Brown
county, Kansas, which he sold in 1909, and made the purchase of his
present farm.
He was married in 1895 to Fanny Kunkel, a daughter of Noah
and Caroline Kunkel, who were residents of Republic county, Kansas,
from 1867 until their death. Mrs. Walter was also a teacher for eight
years, and lived in Republic county over forty years. Mr. and Mrs.
Walter have two living children: Frank, born in 1898, and Ruth, born
in October, 1902.
Mr. and Mrs. Walter are members of the Methodist Episcopal
church. Politically, Mr. Walter is an independent voter, who is not
tied to the principles of any political party or leader. He is a member
of the Central Protective Association.
 HEKELNKAEMPER BROTHERS.
This firm has the distinction of operating the oldest soda and
vinegar manufactory in Kansas, which was founded by William H.
Hekelnkaemper, father of the present proprietors, in 1863. The first
factory was located in a little shed, 14×14 feet, one door east of the A.
J. Harwi hardware store on Commercial street, Atchison, Kan. Mr.
Hekelnkaemper operated the business for ten years, and gradually
enlarged his quarters as much as his limited means would allow, and
about 1873 removed the plant to the present location on the corner of
Ninth and Laramie streets. He erected a brick structure, 22×50 feet,
and also built an ice house. His business prospered from the start
when he moved to his new location, and was confined to the trade in
Atchison with the exception of supplying the towns within a radius of
fifty miles in northeast Kansas, and western Missouri. In the old days
patrons drove in wagons for a distance of fifty miles and more to
purchase the products of the factory, and many of the former patrons
are still buying from the sons. After the founder’s death in 1881, the
business was allowed to languish to some extent owing to the
enforcement of the State prohibition law, for the reason that the
products of the factory, while not intoxicating, were largely
purchased by saloons. Trade naturally fell off for a time until
conditions were adjusted to the new regime, and new demands were
created in other retail circles than the saloon business. The plant was
closed for about a year and the widow then leased the buildings for
ten years to M. L. Greenhut, who later retired. The sons then took
charge in 1900, and it has since been operated by F. W. and G. A.
Hekelnkaemper. The boys had no capital to begin with, but had a
wonderful amount of determination and perseverance which stood
them in good stead and enabled them to make good. The business
had to be built over again, but fortunately paid a small profit during
the first years. In time other additions were made to the plant and
the capacity has been increased to over 15,000 bottle of soda water
per day. This is the main product of the factory which also produces
fruit syrups and flavoring extracts of a superior grade and quality, in
addition to fifty thousand gallons of high grade vinegar each year.
During the busy season fourteen men are employed and
Hekelnkaemper Brothers has grown to become one of the important
manufacturing concerns of Atchison. During the past eight years the
business has practically doubled itself over that of each preceding
year.
William H. Hekelnkaemper, Sr., was born in April of 1837, in
Westphalia, Germany, and emigrated from his native land when a
young man. He landed at New Orleans from a sailing vessel and then
came by river boat to St. Louis where he lived for a number of years
and engaged in the grocery business. His store was burned and he
left St. Louis and came to the town of Rollin, Mo., where he again
established a grocery store about 1861. In the spring of 1863, he
came to Atchison, Kan., and opened and operated the first pool and
billiard room in the city. One year later he disposed of part of his
equipment and moved a part to Seneca, Kan., where after operating a
pool room for a time, he sold out and returned to Atchison. In about
1863 he embarked in the soda manufactory as stated in the
preceding paragraph. While a resident of St. Louis, Mr.
Hekelnkaemper was married to Theresa Houk, who was born in St.
Louis, Mo., of German parents, who both died during the great
cholera epidemic when Theresa was about three years of age. The
children born to this union are as follows: Gustave A., Frederick W.;
William G., Frank V., Laura, Edith, Emma and Anna.
F. W. Hekelnkaemper was married September 17, 1901, to
Pauline Ostertag, a daughter of George Ostertag, one of the pioneer
wagon makers of Atchison, and to this union have been born two
children: Irene and Lucille. He is a Democrat and is a member of the
Elks, Eagles and the Moose.
G. A. Hekelnkaemper is associated with F. W. in the business as
above mentioned. He was married in August, 1901, to Lydia Weik, a
daughter of Christian Weik, an Atchison county pioneer, and to this
union have been born two children: Marie and Louise. G. A. is a
Democrat in politics.
William H. Hekelnkaemper died August 20, 1881. He was
politically allied with the Republican party during his life, and was a
member of the Atchison city council for a number of years, having
been a particular and close friend and admirer of the late Senator
John J. Ingalls. He was one of the founders of the famous Turner
Society, and was its first president. He was prominently identified
with the affairs of the society and the civic affairs of Atchison until
his demise. He was a man of great resourcefulness which aided him
in making a new start on occasions when everything looked darkest
for his future. He had many warm friends in Atchison and was
universally respected by all who knew him.
 CLEM P. HIGLEY.
Clem P. Higley, farmer and stockman of Center township,
Atchison county, was born there March 25, 1869. He is a son of
Russell and Carrie (Hooper) Higley, who were the parents of nine
children, as follows: William, deceased; Otto, deceased; Emma
Winsor, Las Vegas, N. M.; Hallie Nelson, Las Vegas, N. M.;
Theodore, a traveling man; Clem, the subject of this sketch; Frank,
farming the old home place, and Gilbert and Mina, both deceased.
The father was born just west of New York City, January 3, 1833. In
his early manhood he followed the blacksmithing trade, and at the
age of twenty went to Illinois, where he remained for two years.
Coming to Atchison county, he preëmpted 160 acres of land in
section 3, Center township, and sold it shortly afterward and bought
80 acres in section 35, a mile east of old Pardee, Kan. He made
extensive improvements on this place and farmed it until he retired
in 1895. He now lives with his son, Clem. Russell Higley’s life did not
run as smoothly as it might seem from this account of it. In his early
days in Kansas the drought destroyed his crops one year. He
gathered only one bushel of corn from his field that year. Having
started out with no capital, this misfortune was a serious one. He and
his twin brother, Russell, worked for Pardee Butler, while he
returned to Illinois. They worked for Mr. Butler all summer and in
the fall of 1856 started to walk back to Illinois, so as to be home
during the winter. A winter in Kansas was a serious thing in those
days, and with the best of provisions, it was a fierce ordeal. In the
spring of 1857 they returned to Kansas, having the confidence in this
country to develop into a prosperous district. Russell was a son of
Francis Higley, and his mother died when he was a very small boy.
Carrie Higley, the mother of Clem, was born in Tennessee in 1837.
Her father was a freighter from Missouri to Santa Fe, N. M. Mrs.
Higley died in 1899.
Clem Higley, the subject of this sketch, attended school at
Pardee, Kan., and when twenty-one years old, started out to work by
the month. A year later he rented a farm in Benton township, five
miles south of Effingham, Kan. Then for a period of nine years he
rented in Benton township, and the following three years rented his
father’s farm and in 1903 bought 105 acres. The place was not well
improved and he set to work erecting buildings, and now has a large
two-story home and two barns, one 24×50 feet and the other 40×42
feet. The latter has a cement basement. Higley’s total holdings now
number 185 acres of land. He keeps graded stock, including fine
Poland China hogs. In 1896 he was married to Margaret Hawk, who
was born March 21, 1877, in Ohio. She is a daughter of Lafayette and
Hattie (Pitt) Hawk, both natives of Ohio. Mr. and Mrs. Higley have
had six children born to them, the second child dying in infancy. The
others are, Newell, Wilber, Morris, Marie, Dale. All are living with
their parents. Mr. Higley is a Republican and is a member of the
Christian church.
 WILLIAM E. HUBBARD.
William E. Hubbard, farmer and stockman, Kapioma township,
Atchison county, was born September 8, 1861, in Henderson county,
Illinois. He is a son of Simeon and Mary Ann (Pence) Hubbard, who
were the parents of the following children: Mrs. Lillie O’Connor,
widow living in Muscotah; Mrs. Cora Routh, Kapioma township;
Lewis, farmer, Kapioma township; William, the subject of this
sketch, and two children who died in infancy. Simeon Hubbard, the
father of William, was born March 10, 1840, in Indiana. He was a
farmer in his young manhood, and on coming to Kansas in 1874,
followed the same occupation. Settling near Muscotah, he rented
land for four years, and during this time saved his earnings for future
investment. At the end of four years he had accumulated enough to
buy the farm, and he became a landowner and led a prosperous
career as a farmer. He fed stock for the market as well as grew crops.
He now resides in Muscotah, Kan. The mother of William Hubbard is
also living.
William E. Hubbard grew up on his father’s farm in Illinois and
attended the district school in Kapioma township, Atchison county.
When he was of age he began farming in partnership with his father.
At the age of twenty-eight he was married and located on a rented
farm near his father’s place. He lived there until 1895, when he
bought 180 acres just south of where he had rented. After working
this place seven years, he sold it and bought the 160–acre farm which
he now owns. On this place William has invested a considerable sum
in improvements which include a fine granary. He is a stockholder in
the Grange elevator at Muscotah, Kan. It should also be mentioned
that William keeps graded stock on his farm.
In 1889 he married Martha Routh, who was born near
Leavenworth, Kan., in 1869. They are the parents of seven children
as follows: Jesse, Atchison county; Mrs. Bessie Roberts, Kapioma
township; Fred, Lola, Ollie, Mabel and Frank, all living at home. Mr.
Hubbard is a Democrat and is now serving as a member on the
school board in his district, Rose Valley, No. 49. He is a member of
the Mission church. Mr. Hubbard is a citizen interested in the
welfare of his community and is always active in any project that will
improve his neighborhood.
 DRENNAN L. DAWDY.
Drennan L. Dawdy is a stockman first, last and always.
Pedigrees and prices are his stock in trade, and to talk with Mr.
Dawdy without hearing about his fine stock is impossible. Next to his
family his stock is his pride. Mr. Dawdy confines his stock raising to
the best strains. It is his theory that it never pays to bring up a scrub.
The same amount of feed and the same amount of care, if
intelligently applied to registered animals, will bring in double and
treble returns, Mr. Dawdy believes, and it is his policy not to waste
time on inferior breeds. Mr. Dawdy has a cow that cost him $75. The
former owner of the cow did not see any marks of good blood in the
animal, but Mr. Dawdy did, and he has made $4,000 out of that one
cow in the last seven years. The buying of this cow at the price,
however, was simply a very fortunate investment, as Mr. Dawdy says,
generally speaking, “The highest priced cattle were much the best
investments, and he has paid as high as $800 and $900 for cows and
$1,000 for a bull. He sold one of the calves for $755 and another for
$500. He learned his business well, for he learned it in the best way
possible, from his father. The father, John W. Dawdy, was a breeder
of fine cattle in Illinois and probably inherited that trait from his
parents, who were Kentuckians. The father was born in the blue
grass country March 30, 1840, but at the age of seven was taken by
his parents, Jefferson and Elizabeth (Amos) Dawdy, to Illinois,
where he remained until 1910. While he was living at Abingdon, Ill.,
he met Sarah J. Latimer, to whom he was married May 7, 1847. She
was a daughter of Alexandria and Julia Ann (Hart) Latimer, natives
of Tennessee, and was the mother of six children, three of whom are
living. Drennan, the subject of this sketch, is the oldest. The others
are Norval M. and Daisy E., who live in California. In 1910 the
parents removed to Napa, Cal., where the father is now living. The
mother died August 12, 1915.
After attending the country school near his Illinois home,
Drennan attended Hedding College at Abingdon and later went to
business college at Chicago. But he was a natural born stockman and
could not resist the lure. So he went back to his father and joined him
in the livestock business and became associated with his father in the
breeding of Shorthorn cattle under the firm name of J. W. Dawdy &
Son. In the latter part of 1889 he and Walter Latimer purchased the
entire herd of cattle known as the Shannon Hill herd owned by the
late Ex-Governor George W. Glick, of Atchison, Kan. This herd was
the largest collection of pure Bates cattle in America at that time, and
were dispersed by D. L. Dawdy & Co., at auction in Kansas City, Mo.,
April 11–12, 1900, the ninety-one head bringing a total of $20,460,
which was considered a remarkable sale for an entire herd, which
included a number of aged cows, the general average of the sale
being $225 per head with a top price of $800 for the “Second
Dutchess” of Atchison, the buyer of whom was the late W. R. Nelson,
of the Kansas City Star. Mr. Nelson bought fifteen head of cattle at
this sale at an average price of $415 per head. In June of the same
year this firm bought the entire herd of Scotch and Scotch topped
Shorthorns of J. T. Kinmouth & Son, Columbus Junction, Iowa,
paying $11,000 cash for the 100 head. This was one of the most
notable private deals in registered cattle of recent years. In 1901 they
bought sixty-five head of registered cattle in one lot. D. L. Dawdy &
Co. have made many successful sales both private and public. In
1899 Mr. Dawdy came to Atchison county, Kansas, and took charge
of the George W. Glick farms, near Atchison, Kan. This position gave
him charge of a herd of registered Shorthorns. In 1901 he bought the
farm which he now owns, consisting of 405 acres, lying one-half mile
north of Arrington, Kan. On this place he has devoted himself to the
breeding of fine cattle and has made that his principal work. His
exhibits have taken high honors at the stock shows in Kansas City
and Chicago. A number of years ago he bought “Sunshine,” a fine
cow in the herd owned by Senator W. A. Harris, paying $225 for her.
Four of her calves have brought him $1,365. He has owned three
cows which sold for $800 each, and in 1902 he sold thirty head of
cattle at $266.66 each.
On May 15, 1901, Mr. Dawdy married Nellie B. Prim, who was
born on a farm near Atchison, Kan., April 3, 1881. Her father,
Charles S. Prim, was a native of Tennessee, while the mother, Sophia
(Christian) Prim, came from the Isle of Man. Both parents are now
dead. Mr. and Mrs. Dawdy have four children, all of whom are living
at home: Ruth, John, Helen and Glenn. Two died in infancy. Mrs.
Dawdy carries her husband’s hobbies into the domestic end of the
farm. She makes a specialty of raising fine turkeys, raising the bronze
variety. She sells eggs from her turkeys for fifty cents apiece, and
often gets as high as $7.50 for a turkey. She saved $150 from the sale
of eggs and bought a Shorthorn calf which is worth $300 today. Mr.
Dawdy is working to make his home an ideal country place. His
house is on one of the finest locations in the county. By installing
15,000 feet of drainage, at a cost of $1,200, he has reclaimed fifty-
two acres of soil, which previous owners of the place had thought to
be too wet to cultivate, but since installing the drainage system Mr.
Dawdy has raised annually fine crops of corn and wheat on it. The
Delaware has a habit of overflowing and Mr. Dawdy was one of the
first farmers to suggest the organization of County Drainage District,
Number One, comprising 8,300 acres, and is nine miles in length as
the crow flies, while the Delaware river course is at present nineteen
and one-half miles, and the drainage system shortens the run seven
and one-half miles, doubles the velocity of the stream and increases
its carrying capacity four and one-half times. The expense or total
cost of the ditch will be $100,000 and will increase land values
tremendously. Mr. Dawdy is one of the directors of the enterprise.
Mr. Dawdy owns 405½ acres of land which has a fine large residence
on it. The location is one of the most beautiful in Atchison county.
On a clear day Horton, fifteen miles north, can be plainly seen;
Holton looms up twelve miles west, Muscotah, seven miles north,
Valley Falls, twelve miles southeast, Larkin, two and a half miles
west, and Arrington, one-half mile south. Mr. Dawdy has a complete
set of volumes of American herd books, and knows the pedigree of
every animal on his place. He is a member of the American
Shorthorn Breeders’ Association of Chicago, and knows the latest
facts about the cattle business. His home is highly improved with
silos and drainage facilities. He is a Democrat in politics and a
member of the district school board and the drainage district No. 1,
of Atchison county, Kansas. He belongs to the Ancient Free and
Accepted Masons, of Muscotah.
 JOHN M. PRICE.
John M. Price, deputy county treasurer, farmer and stockman,
of Mt. Pleasant township, Atchison county, is a native born Kansan,
and son of John M. Price, deceased, who was one of the most
distinguished members of the Kansas bar, and who practiced his
profession in the city of Atchison for forty years.
John M. Price, the father, was born in Richmond, Madison
county, Kentucky, in October, 1829, a son of Thomas S. and Sarah
(Jarman) Price. His paternal grandfather was Moses M. Price, and
his maternal grandfather was John Jarman. Moses M. married
Catherine Broadus, and John Jarman married Elizabeth Broadus,
the two women being distant relatives. Moses M. Price and wife were
both natives of Virginia, and removed to Madison county, Kentucky,
in the early part of the nineteenth century, with their respective
parents. After his marriage in Kentucky, Moses M. made his home in
Estill county, Kentucky. He was the father of ten children, the fourth
of whom was Thomas M. Price, father of John M., the elder, and who
married Sarah Jarman in 1828. Sarah (Jarman) Price was a daughter
of John and Elizabeth (Broadus) Jarman. This marriage was blessed
with three children: Thomas E., John M., and Mary W. The mother
died in 1836, and in 1838 Thomas M. Price married Miss Elizabeth
Combs, of Clark county, Kentucky, and the following fall removed to
a home in Johnson county, Missouri. From Johnson county he
removed to Pettis county, Missouri, and farmed there until 1845,
after which he returned to Estill county, Kentucky. In 1853 Thomas
S. and family started for Texas, where he resided until his demise at
Mt. Pleasant, Titus county, in 1857.
John M. Price, father of the present deputy county treasurer,
returned from Missouri to Kentucky with his father, and remained at
the home of his uncle, Morgan M. Price, whom he assisted in his
farm work, and also attended school at Irvine, the county seat of
Estill county. In 1845 and 1846 he was employed in a drygoods store
at Irvine, and in the fall of 1847 he accepted a home with Col. Walter
Chiles, a prominent lawyer and politician of Mt. Sterling, Ky., who
had married Jane Price, an aunt of John M. Price. After attending
school in the fall and winter, Mr. Price became a clerk in the office of
the county clerk of Montgomery county, Kentucky. While performing
his duties in the county clerk’s office he read law in the office of
Colonel Chiles and was admitted to the practice of his profession in
March, 1848. He first opened a law office at Irvine, and in 1851 was
elected county attorney of Estill county; reëlected in 1855, and
continued to serve until July, 1858, when he resigned in order to
remove to Kansas. He determined on Atchison as his future abiding
place, and accordingly, located in this city September 1, 1858.
Kansas was then a territory, and for forty-one years of the
development of the State, Mr. Price was an important factor in
promoting its interests and welfare. He soon built up an extensive
law practice in the growing city of the great bend on the Missouri,
and took an active and influential part in political affairs, allying
himself with the newly formed Republican party. He early identified
himself with the controlling organization of his party, and for twenty
years prior to his demise he was a delegate to every Republican
county convention, and to many State conventions. In 1859, when
Judge Otis resigned the office of county attorney, Mr. Price was
appointed to fill the vacancy by the board of county commissioners,
and served until Kansas was admitted into the Union, when he was
nominated and elected to the office at the first general election under
the State constitution. In 1861 he was elected police judge of the city
and re-elected in 1862 and 1863. He was elected a member of the city
council in 1864 and served for three years in succession as a member
of that body. He was elected mayor of the city without opposition in
1867. In the fall of 1866 he was elected State senator from Atchison
county for a two years’ term, and while serving as State senator he
was appointed by Governor Crawford as one of the commissioners to
revise the general laws of the State. Mr. Price was chairman of the
commission, which was composed of himself, Samuel A. Riggs, of
Lawrence, and James McCahon, of Leavenworth. The revision thus
made was adopted by the legislature without much amendment, and
the general statutes of 1868 were printed and published during that
year under the supervision of this commission. In the same year Mr.
Price was made chairman of the judiciary committee of the senate, to
which body he was reëlected in 1870, and served during the sessions
of 1871 and 1872, and on the organization of the senate, he was
chosen president of the body. He was a candidate for governor of the
State before the Republican convention in the fall of 1872, and was a
leading candidate until the tenth and last ballot, when all the
opposing candidates threw their support to Thomas A. Osborne. In
the memorable contest for the United States senatorship in 1873, Mr.
Price’s friends presented him as a candidate before the anti-Pomeroy
caucus, and for the first nineteen ballots Mr. Price was the leading
candidate, and then John J. Ingalls was chosen by the convention on
a unanimous vote. In 1892 he was again elected to the State senate
and served in the memorable sessions of 1893 and 1895.
On January 10, 1854, John M. Price was married in Irvine, Ky.,
to Eliza Jarman Park, the only daughter of Elihu and Mary Park. This
marriage was blessed with the following children: Mollie F., born in
Irvine, October 12, 1854, married Charles B. Singleton, of Atchison,
for twenty-seven years assistant postmaster, and now bookkeeper for
the Exchange National Bank; Nannie B., born in Irvine August 28,
1856, wife of F. L. Vandergrift, editor of the Santa Fe publications,
Kansas City, Mo.; John M. died in January, 1875; John M., Jr., with
whom this review is directly concerned, and Eliza P. The mother of
these children was born in Irvine, Ky., August 22, 1832, and resides
at present in Kansas City, Mo.
John M. Price, Sr., died October 19, 1898. He was one of the
distinguished Masons of Kansas. He served as the grand high priest
of the Grand Royal Arch Chapter of Kansas, and was secretary of that
body: he was president of the council of the Holy Order of High
Priesthood; grand treasurer of the Grand Council of Royal and Select
Masters of the State; also president of the Kansas Masons’ Protective
Association; was a thirty-second degree Mason, and a member of
Medina Temple, No. 31, of the Mystic Shrine, and was also a member
of Shiloh Conclave, No. 1, Knights of the Red Cross of Constantine,
Knights of the Holy Sepulchre, and Knights of St. John the
Evangelist. He served one term as grand master of the most worthy
grand lodge of the Odd Fellows, and was twice elected a grand
representative to the grand lodge of the United States. He served one
term as grand chancellor of the grand lodge, and of the Knights of
Pythias was the supreme representative to the supreme lodge of the
world for four years. He was the grand master workman of the grand
lodge of the Ancient Order of United Workmen of Kansas; was a
member of the grand lodge of the Knights of Honor, served as
assistant director, and as president of the Atchison lodge of the
Independent Order of Mutual Aid. For years a distinguished and able
member of the legal profession, he was one of the most respected
and useful citizens of Atchison and the State of Kansas.
John M. Price, whose career naturally follows that of his
distinguished parent, was born March 27, 1876, in Atchison. He was
educated in the public schools, and graduated from Midland College
in 1894. After completing the course in Midland College, he entered
Wittenberg University, at Springfield, Ohio, and was graduated from
that institution in 1897, with the degree of Master of Arts. For some
time he was engaged in the profession of teaching, and was assistant
professor of chemistry and physics at Midland College from 1894
until 1895. For two years he filled the post of buyer at the Kansas
State penitentiary, at Lansing, and then located on his farm in Mt.
Pleasant township, near the city of Atchison. He followed farming
and stock raising with success. He was appointed deputy county
treasurer under U. B. Sharpless in the fall of 1915, and is now filling
the duties of his office faithfully and conscientiously.
Mr. Price was married August 12, 1903, to Miss Fan Ballew, who
has borne him one child, Jane Ballew Price, born June 2, 1911. Mrs.
Price was born in Madison county, Kentucky, March 19, 1885, a
daughter of George W. and Jennie (Francis) Ballew, both of whom
were descended from old Kentucky families It is a matter of history
that the grandfather of Mrs. Price, Francis, by name, owned the
slaves which escaped from the Kentucky plantation across the Ohio
river, and from whom the character, Eliza, in “Uncle Tom’s Cabin”
was taken.
Undoubtedly, John M. Price is one of the rising young men of
Atchison county, who is at the beginning of a career which is
destined to reflect credit upon the memory of his illustrious father.
He is a member of the Benevolent and Protective Order of Elks, and
is the present exalted ruler of that body, and is a prominent member
of the Ancient Order of United Workmen, and the Fraternal Aid
Union.
 BOYD ROYER.
Boyd Royer, farmer and stockman, of Kapioma township,
Atchison county, Kansas, has reason to be proud of his family tree.
His mother was the first white child to be born in Kapioma township,
Atchison county. She was Emma Hammond before her marriage to
George Royer, and was born in 1861 to William and Lena (Brutton)
Hammond, who came over from Missouri and settled in Kansas a
short time before her birth. Her ancestors were Kentuckians. The
father of Boyd Royer was a Pennsylvanian, having been born in
Union county, that State, in 1859. He grew up with the common
schooling of the time and learned the blacksmith’s trade. Coming to
Kansas in 1879, he worked by the month near Effingham for a while
and later engaged in farming in Kapioma township, where he rented
a farm until his retirement in 1910. when he moved to Valley Falls,
Kan.
Boyd Royer, the subject of this sketch, was born May 13, 1881,
four miles east of Arrington, Kan. He was the oldest child of four
children. The other children are: Walter, with the J. I. Case
Company, Kansas City, Mo.; Miles, a Government employee,
Washington, D. C, and George, Kansas City, Mo. The mother died in
1905. Boyd Royer grew up on his father’s farm and attended school
in district No. 31 of Kapioma township. In 1901 he rented land near
Arrington, Kan., and in 1909 bought 160 acres, and built a fine barn,
36×36 feet, on this place and has a large eight-room house on the
place. All buildings are well painted and kept in excellent condition,
and everything around the place is kept in neat order.
In 1905 Boyd Royer married Mabel Beyer, who was born June
26, 1882, in Kapioma township, Atchison county. She is a daughter
of Asa and Susan Beyer, both natives of Pennsylvania, who came to
Atchison county in the early days. Mr. Royer is a Republican. He is a
steward in the Methodist Episcopal church. Mr. and Mrs. Royer have
no children.